[Flaky CI]: Cloudflare Integration Tests - suites/tracing/workflow/test.ts > Workflow steps create transactions with correct attributes

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

Cloudflare Integration Tests

Name of Test

suites/tracing/workflow/test.ts > Workflow steps create transactions with correct attributes

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/27837096414/job/82388178508

---

This issue was automatically created.

[linear-code]

JS-2812

[github-actions]

Automated triage of this flaky test

I looked into suites/tracing/workflow/test.ts > Workflow steps create transactions with correct attributes but am not opening a PR because I could not confirm the exact failure mode from the CI job log (the logs endpoint was not reachable in this unattended run), and every candidate fix would loosen an assertion. Here is what I found so the fix can be made with confidence.

How this test can fail (the only paths)

The test registers two expected transaction envelopes (step-one, step-two) and calls .unordered(). In unordered mode the runner silently drops any envelope that doesn't match an expected one (runner.ts findIndex(...) < 0 → return) and never calls reject. So the test can only fail via:

1. Timeout (30s) — one of the two expected envelopes never matches, so completed() never resolves. Because mismatches are dropped silently, a single unexpected/missing attribute on the trace context looks identical to a lost envelope.
2. A transient non-ok response from GET /workflow/trigger (already largely mitigated: fetchWithRetry retries 500s).

Path (1) is the likely flake.

The brittle spot

This test matches the entire contexts.trace object and the entire data object as bare literals — i.e. exactly these keys, no more:

trace: {
  span_id: expect.any(String),
  trace_id: expect.any(String),
  op: 'function.step.do',
  origin: 'auto.faas.cloudflare.workflow',
  status: 'ok',
  data: { /* exactly 5 keys, incl. 'cloudflare.workflow.attempt': 1 */ },
},

By contrast, the sibling workflow-step test suites/tracing/propagation/workflow-do/test.ts asserts the same kind of function.step.do transaction with expect.objectContaining(...) for both trace and data, and is not flagged flaky. Any field the local Workflows runtime adds non-deterministically (e.g. a parent_span_id, or cloudflare.workflow.attempt being absent on runtime versions that don't pass the step context — see the "April 2026+" feature-detection note in packages/cloudflare/src/workflows.ts) would fail the exact match here but pass the sibling's objectContaining.

Suggested fix (for a human to confirm against a real failure log)

Mirror the sibling test: wrap the trace and data matchers in expect.objectContaining(...) while keeping the specific assertions (op, origin, status: 'ok', the five data attributes). This preserves what the test actually verifies (the workflow-step attributes) while removing the brittle "no extra keys" constraint that the sibling test already avoids.

To fix it correctly rather than blindly, please grab the failing assertion diff from a reproduction (or the 1) [chromium]/expect(received) block in the job log) to confirm which field varies — then loosen only that field.

[github-actions]

A PR closing this issue has just been released 🚀

This issue was referenced by PR #22083, which was included in the 10.65.0 release.