[Workers] integration testing guide with createTestHarness()#31422
[Workers] integration testing guide with createTestHarness()#31422edmundhung wants to merge 4 commits into
createTestHarness()#31422Conversation
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
There was a problem hiding this comment.
Verdict: 2 style issues to address. Inline suggestions posted.
Issues
- LOW
src/content/changelog/workers/2026-06-16-test-harness-api.mdx:2— API name in changelog title should be wrapped in backticks. - LOW
src/content/docs/workers/testing/unstable_startworker.mdx:20— Workers TypeScript examples must use theTypeScriptExamplecomponent instead of a baretsfence.
Out-of-scope note
PR references a workers-sdk fixture that will only exist once cloudflare/workers-sdk#14278 is merged. Coordinate merge timing so the link does not 404.
|
Review posted on PR #31422. Labels: Already appropriately labeled ( What this PR changes
Issues found
Both style issues have inline suggestions on the PR. |
Review for PR #31422Labels: Already appropriately labeled ( What this PR changes
Validation status
Issues found
Inline suggestions
+ Remove the unused
Out-of-scope note |
…ams polling Previously each style-guide child dispatch used ?wait=result, holding a synchronous HTTP request open to the child DO until it completed. If that response path dropped (child finished but parent never received the result), the parent's Promise.all would hang indefinitely. Observed in PR #31422: all 11 child runs completed on the child side, but one parent-side style_guide_child_dispatch_complete was never logged. New approach: - Invoke each child in accepted mode (no ?wait=result); receive runId in 202 - Poll /runs/:runId via Durable Streams long-poll until run_end is observed - Each long-poll subrequest has a bounded lifetime (<=30s per Flue protocol) - Resume from offset after each response so no events are missed - If run_end.isError, throw with the actual error message - If deadline (5 min) exceeded without run_end, return empty result with a timeout log rather than hanging the parent forever New log actions: - style_guide_child_run_admitted - style_guide_child_run_observe_start - style_guide_child_run_observe_complete - style_guide_child_run_observe_failed - style_guide_child_run_observe_timeout - style_guide_child_run_observe_fetch_error - style_guide_child_run_observe_error
| @@ -0,0 +1,81 @@ | |||
| --- | |||
| title: Test Workers the way they are built with createTestHarness | |||
| description: Run integration tests against your Workers' production build output from any Node.js test runner. | |||
There was a problem hiding this comment.
This line is much clearer than "the way they are built" in the title
Run tests against your Worker's production build using any Node.js test runner
Something like that?
There was a problem hiding this comment.
I would prefer keeping integration tests in the title to distinguish this from vitest-pool-workers. How about this?
title: Run integration tests against your Worker's production build
description: Use Wrangler's `createTestHarness` API to test production build output from any Node.js test runner.
| }); | ||
|
|
||
| test("routes requests to each Worker", async ({ expect }) => { | ||
| network.use( |
There was a problem hiding this comment.
Is this right? Doesn't seem to relate to the rest of the test in terms of routing @edmundhung
There was a problem hiding this comment.
It's there to showcase how to mock outbound request. We can drop it.
There was a problem hiding this comment.
If we're going to keep it I'd just put a comment line above showing that, it's not clear how it relates to this example.
There was a problem hiding this comment.
Added a comment above in 460a32a. I have also moved the publish date to tomorrow (18 Jun).
There was a problem hiding this comment.
Just updated in 70635e7 to mention both two unstable APIs are now deprecated too.
Review⏸️ Automatic reviews for this PR are paused. This PR has already received 2 automatic reviews. To run another review, a codeowner can comment
Warnings (1)
Suggestions (1)
CommandsOnly codeowners can run commands. Post a comment with the command to trigger it.
|
…ble Streams polling, and refactor domain logic into lib/ (#31436) * [flue] Reduce style-guide fan-out concurrency and scope child hydration by filename - Lower STYLE_GUIDE_CONCURRENCY from 10 to 5 to reduce concurrent DO memory pressure - When a filename is specified, hydrate only manifest.json, pr.json, comments, and the single patch file instead of listing every object in the diffDir prefix - Re-enable and improve fan-out structured logs in code-review-orchestrator: style_guide_fanout_start, style_guide_complete, and per-child dispatch events - Add filename to all style-guide-review log events for per-child observability - Add hydration_start/hydration_complete logs with object counts * [flue] Avoid redundant R2 GETs for manifest.json and pr.json in targeted hydration manifest.json and pr.json are already fetched earlier in the run function (for the fast-fail check and PR metadata read). Reuse their in-memory text instead of re-fetching from R2 inside the targeted diffKeysToLoad branch. Only comments and the patch file are fetched fresh in targeted mode. * style: format * [flue] Fix Body already used error in targeted hydration manifestObj.text() was called at parse time (step 1) and then again inside the cachedDiffResults block. Same for prObj.json() then prObj.text(). R2 response bodies are single-use streams — reading twice throws TypeError. Fix: capture manifestText and prText as strings on first read, reuse them for both parsing and workspace write. * [flue] Log actual error before Flue swallows it as generic 500 Wrap the style-guide-review run body in a top-level try/catch that logs the error message and stack with full context (PR number, filename, diffDir, runId) before rethrowing. Previously any unhandled throw was caught by Flue and surfaced to the parent orchestrator only as a generic 500 internal_error with no child-side log, making the root cause invisible in Workers Observability. * style: format * [flue] Replace ?wait=result fan-out with accepted mode + Durable Streams polling Previously each style-guide child dispatch used ?wait=result, holding a synchronous HTTP request open to the child DO until it completed. If that response path dropped (child finished but parent never received the result), the parent's Promise.all would hang indefinitely. Observed in PR #31422: all 11 child runs completed on the child side, but one parent-side style_guide_child_dispatch_complete was never logged. New approach: - Invoke each child in accepted mode (no ?wait=result); receive runId in 202 - Poll /runs/:runId via Durable Streams long-poll until run_end is observed - Each long-poll subrequest has a bounded lifetime (<=30s per Flue protocol) - Resume from offset after each response so no events are missed - If run_end.isError, throw with the actual error message - If deadline (5 min) exceeded without run_end, return empty result with a timeout log rather than hanging the parent forever New log actions: - style_guide_child_run_admitted - style_guide_child_run_observe_start - style_guide_child_run_observe_complete - style_guide_child_run_observe_failed - style_guide_child_run_observe_timeout - style_guide_child_run_observe_fetch_error - style_guide_child_run_observe_error * style: format * [flue] Apply accepted-mode + Durable Streams polling pattern everywhere Extract shared admitWorkflow() and pollRun() helpers into lib/poll-run.ts so the pattern is consistent across all orchestrators. orchestrate.ts: - Dependabot PR events (3a): fire-and-forget admitted mode — result is not needed by the orchestrate workflow; the dependabot-review workflow handles its own GitHub output - /full-review and /review slash commands (3, 4): same — fire-and-forget; result discarded in original code too - Spam filter (5): admit + poll, since the closed boolean determines whether to run code review. Timeout treated as 'not spam' to avoid blocking review - Code review orchestrator (6): fire-and-forget admitted mode — it posts its own GitHub comment when done; orchestrate does not need to wait code-review-orchestrator.ts: - Replace inline dispatchStyleGuideReview / pollStyleGuideRun with a thin wrapper over the shared admitWorkflow() + pollRun() helpers - Keeps all existing structured log actions intact lib/poll-run.ts (new): - admitWorkflow(): POST to any workflow pathname, return runId from 202 - pollRun<T>(): poll /runs/:runId via Durable Streams long-poll until run_end, with configurable timeout and transient error retry * style: format * [flue] Upgrade model to kimi-k2.7-code across all workflows * [flue] Extract model constants into lib/models.ts Add lib/models.ts with PRIMARY_MODEL and RECONCILIATION_MODEL. Replace hardcoded model strings in all four workflow files. * Revert "[flue] Extract model constants into lib/models.ts" This reverts commit 23ab445. * [flue] Extract style-guide result types/schemas into lib/style-guide-results.ts Move StyleGuideFindingFromModelSchema, StyleGuideResultFromModelSchema, StyleGuideFinding, StyleGuideResult, and assignFindingIds out of the workflow file into a shared lib. style-guide-review.ts re-exports the public types; code-review-orchestrator.ts imports directly from lib. * style: format * [flue] Extract style-guide workspace hydration into lib/style-guide-hydration.ts * style: format * [flue] Extract style-guide fan-out mechanics into lib/style-guide-fanout.ts * style: format * [flue] Extract code-review diff/state helpers into lib/code-review-diff.ts and lib/code-review-state.ts * style: format * [flue] Extract code-review comment rendering into lib/code-review-render.ts * style: format * [flue] Extract GitHub webhook parsing helpers into lib/github-webhook.ts * style: format * [flue] Extract spam-filter domain helpers into lib/spam-filter.ts * style: format * [flue] Extract Dependabot review helpers into lib/dependabot-review.ts * style: format * [flue] Fix redundant R2 GETs in full hydration mode and misleading acted:true on dispatch failure --------- Co-authored-by: cloudflare-docs-bot[bot] <cloudflare-docs-bot[bot]@users.noreply.github.com>
Summary
Adding API reference and some guides with regards to the new
createTestHarness()API, which is now our recommendation for integration tests.This fixture mentioned in the examples page will be available once cloudflare/workers-sdk#14278 is merged.
Screenshots (optional)
Documentation checklist