Skip to content

test(time-profiler): stabilize flaky "should update state"#362

Open
szegedi wants to merge 1 commit into
mainfrom
fix-flaky-time-profiler-state
Open

test(time-profiler): stabilize flaky "should update state"#362
szegedi wants to merge 1 commit into
mainfrom
fix-flaky-time-profiler-state

Conversation

@szegedi

@szegedi szegedi commented Jun 26, 2026

Copy link
Copy Markdown

What

Stabilizes the intermittently-failing Time Profiler › profile › should update state test, which flakes across platforms (e.g. centos-test-26, darwin-arm) with either No context found or Unexpected context.

Root cause

Two compounding issues:

  1. Context was often never stored. The test established the sampling context with a bare time.setContext(initialContext). Under useCPED, setContext only takes effect when the current continuation already has an AsyncContextFrame (the native side bails with if (!cped->IsMap()) return;); otherwise it silently no-ops. Whether such a frame existed depended on what ran before the test, so the context was frequently never stored and samples came back with an undefined context → Unexpected context. (Run in isolation on Node 26 it failed 100% for this reason.)

  2. It stopped after a single sample. The wait loop exited as soon as kSampleCount reached 1. The first sample is taken at profiler start — before any context is set — and is explicitly skipped during context association (GetContextsByNode), so a single sample left nothing reliable to attach the context to → No context found.

Fix

  • Establish the context the way production code does: time.runWithContext(...) when useCPED is enabled (which reliably installs the AsyncContextFrame), and setContext(...) otherwise.
  • Wait for several samples before stopping, so a genuine, context-bearing sample is present and associated.

The test still verifies the same things (context associated with samples, the stored context reflects a live mutation of the object, and timestamps fall within range).

Verification

Reproduced and verified on Node 26 (in a container):

before after
isolated (--grep), 30 runs 0 pass / 30 fail 30 pass / 0 fail
full test file, 3 runs flaky 25 passing each

🤖 Generated with Claude Code

The test was intermittently failing across platforms (e.g. centos-test-26,
darwin-arm builds) with either "No context found" or "Unexpected context".

Two compounding causes:

1. It established the sampling context with a bare setContext(). Under
   useCPED that only takes effect when the current continuation already has
   an AsyncContextFrame; otherwise it silently no-ops. Whether one existed
   depended on what ran before, so the context was often never stored and
   samples came back with an undefined context.

2. It stopped after a single sample. The first sample is taken at profiler
   start (before any context is set) and is skipped during context
   association, so one sample left nothing reliable to attach the context to.

Establish the context the way production code does — runWithContext when
useCPED is enabled, setContext otherwise — and wait for several samples
before stopping. Reproduced on Node 26: the test failed 30/30 runs in
isolation before, and passes 30/30 in isolation and 25/25 in the full file
after.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@datadog-official

Copy link
Copy Markdown

Pipelines

Fix all issues with BitsAI

⚠️ Warnings

🚦 1 Pipeline job failed

Pull Request Labels | label   View in Datadog   GitHub Actions

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: e432cdd | Docs | Datadog PR Page | Give us feedback!

@github-actions

Copy link
Copy Markdown

Overall package size

Self size: 2.19 MB
Deduped: 2.89 MB
No deduping: 2.89 MB

Dependency sizes | name | version | self size | total size | |------|---------|-----------|------------| | pprof-format | 2.2.2 | 500.53 kB | 500.53 kB | | source-map | 0.7.6 | 185.63 kB | 185.63 kB | | node-gyp-build | 4.8.4 | 13.86 kB | 13.86 kB |

🤖 This report was automatically generated by heaviest-objects-in-the-universe

@szegedi szegedi added the semver-patch Bug or security fixes, mainly label Jun 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

semver-patch Bug or security fixes, mainly

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant