Repository navigation
[avenger] Fix compiled work queue launch receipt assertions - #69057
Conversation
Assert durable requests with blocked launch details when credential or tag validation fails, retaining no-launch safety checks. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅
|
|
✅ PR Code Quality Reviewer completed the code quality review.
|
|
✅ Ponytail Reviewer completed successfully! Ponytail ReviewerOutcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
|
✅ Test Quality Sentinel completed test quality analysis. Test Quality SentinelOutcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
|
✅ Design Decision Gate 🏗️ completed the design decision gate check. See the comment below for the result and any generated ADR draft. Design Decision Gate 🏗️Outcome: The agent completed and reported no action. A no-op output alone does not verify that all required work was completed or that publication was possible. Agent messages are omitted from this comment. The category uses structured run status, not interpretation of agent prose.
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Skills-Based Review 🧠
Applied /diagnosing-bugs — no actionable issues found; approving.
📋 Analysis
The change updates verifyCompiledDispatchIdentity in work_queue_control_adapter_checks.cjs to assert the correct receipt shape for wrong-credential / wrong-dispatch-tag modes: a durable receipt (status: "durable"), success: false, and a single launches[0] entry with state: "blocked", failure_stage: "launch_processing", and the precise mismatch reason.
I cross-checked this against the production implementation in work_queue_dispatch.cjs (around line 470-510):
statusis set to"durable"whenevergroups.length(assignments) is non-zero, independent of individual launch outcome.successis computed aslaunches.every(launch => ["bound","released","staged_preview"].includes(launch.state)), so a blocked launch correctly yieldssuccess: false.- Blocked launches are pushed with
state: "blocked",reason: queueControlErrorCode(error), andfailure_stage: "launch_processing".
The new assertions match this behavior exactly, and are consistent with equivalent patterns already present elsewhere in the same test file (e.g. lines 264-267). The fix correctly addresses the root cause described in the PR body (the runtime preserves the durable request and records the blocked launch separately, rather than marking the whole receipt as blocked) rather than papering over a symptom. This is a test-only change; no production code or workflow files are touched, matching the PR description.
Positive Highlights
- ✅ Root cause correctly diagnosed per
/diagnosing-bugs: distinguishes receipt-level durability from launch-level failure instead of loosening the assertion. - ✅ New assertions are specific (dispatch_id, failure_stage, exact reason per mode) rather than a loose/weakened check.
- ✅ Preserves pre-existing assertions (no dispatch POST, reservation retained, no started-transition published).
- ✅ Change is narrowly scoped to the test helper, matching the stated intent.
No regression-test gap or masking behavior identified; nothing further to request.
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · copilot · sonnet50 · 21.7 AIC · ⌖ 14.5 AIC · ⊞ 11.1K
Comment /matt to run again
There was a problem hiding this comment.
Verdict
I don’t see a merge-blocking problem in this patch. It updates the helper to assert the durable receipt shape the runtime already returns for blocked launches, and the added checks make the failure mode materially more specific.
Reviewed areas
- Wrong-credential and wrong-dispatch-tag receipt semantics
- Preservation of the reserved dispatch state and no-started-transition invariant
- Risk of overfitting the helper to unstable fields in the changed assertions
I did not find an actionable correctness, performance, or maintainability regression in the changed lines.
🔎 Code quality review by PR Code Quality Reviewer · copilot · gpt54 · 11.1 AIC · ⌖ 5.52 AIC · ⊞ 21.4K
Comment /review to run again
There was a problem hiding this comment.
🟢 Approval recommended
The focused test-only change matches the runtime contract and preserves dispatch-safety checks.
0 open findings
What changed in this PR
Corrects compiled work-queue integration assertions to match durable receipts with separately blocked launches. Production behavior is unchanged.
Changes:
- Checks receipt status, unsuccessful outcomes, and blocked-launch identity and failure details.
- Preserves no-dispatch, reserved-assignment, and no-started-transition assertions.
| File | Description |
|---|---|
| actions/setup/js/work_queue_control_adapter_checks.cjs | Corrects receipt and launch assertions for credential and tag validation failures. |
🧠 Review effort: Max
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
|
One or more custom setup steps configured for this repository failed during this Copilot code review run: Setup steps run before each review. If the review above is missing context, or no review was posted at all, the failing step above may be the cause. See the workflow run for failure details, fix your setup steps configuration, and re-request a review. Note You can configure setup steps for Copilot code review separately from Copilot cloud agent with a |
|
🎉 This pull request is included in a new release. Release: |
CI failure and repair
CI run 38749868868 failed in Integration: Workflow Misc Part 2.
TestWorkQueueCompiledPolicyAndLaunchIdentityexpected a blocked request after credential or tag validation failed, but the runtime correctly preserves the durable request and records its blocked launch separately.Update the integration helper to assert the durable receipt, unsuccessful outcome, and one blocked launch with the matching dispatch ID, failure stage, and precise error reason. Preserve assertions that no workflow dispatch occurs, the assignment stays reserved, and no started transition is published. Production behavior is unchanged. Only one test-helper file is modified; no workflow files are included.
Validation
make agent-report-progresspassed: build, changed-file formatting and JavaScript lint, schema check, and impacted-test gate. JavaScript lint reported 20 existing warnings and zero errors. The gate invokedmake test-unit, which skipped Go unit tests because no Go files changed; its JavaScript selector found no tests, so the two explicit suites above were run separately.git diff --checkpassed. Fullmake fmtandmake lintwere not run for this targeted JavaScript test-only repair.Environment limitations
git fetch origin mainfailed certificate verification; TLS verification was not bypassed. The existingorigin/mainalready matched checkout commitb751436ce667ee01f7e4afb4472bd2c8c1f3897a, and merging that available ref was a no-op. No valid steering issue number was supplied, so steering comments could not be queried.