fix(router): prefer trigger result work-item id over parse-time field in decisionReason#1239
Merged
zbigniewsobiecki merged 5 commits intodevfrom Apr 29, 2026
Merged
Conversation
Merge dev → main: Fix 1 (BullMQ coalesce unique jobIds) + Fix 2 (snapshot rmi on PR merge)
Merge dev → main: backlog-manager scope safety (#1233)
Merge dev → main: respond-to-ci diagnostics + persona-scope hardening (#1235)
Merge dev → main: refactor(triggers) consolidate handler boilerplate (#1237)
… in decisionReason Prod incident 2026-04-29: a `respond-to-ci` dispatch logged `Job queued: respond-to-ci agent for work item (unknown)` even though the agent ran on the right PR. Root cause: the GitHub adapter's `parseWebhook` extracts `event.workItemId` from `payload.pull_request.number` only — `check_suite` webhooks store the PR number under `payload.check_suite.pull_requests[0].number` and the parser leaves the field undefined. The `respond-to-ci` handler resolves the PR internally and returns it as `result.prNumber` + `result.workItemId`, but the decisionReason builder used the parse-time `event.workItemId`. The agent itself fired correctly; only the dashboard webhook log was affected. Fix: a `resolveWorkItemLabel(result, event)` helper picks the most specific label — `result.workItemId > 'PR #' + result.prNumber > event.workItemId > '(unknown)'`. Both the `Coalesced dispatch scheduled` and `Job queued` build sites use it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
zbigniewsobiecki
added a commit
that referenced
this pull request
Apr 29, 2026
Merge dev → main: decisionReason work-item-id resolution (#1239)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Prod incident 2026-04-29: a
respond-to-cidispatch loggedeven though the agent fired correctly on the right PR. Root cause: the GitHub adapter's
parseWebhookextractsevent.workItemIdfrompayload.pull_request.numberonly —check_suitewebhooks store the PR number underpayload.check_suite.pull_requests[0].numberand the parser leaves the field undefined. Therespond-to-cihandler resolves the PR internally and returns it asresult.prNumber+result.workItemId, but the decisionReason builder used the parse-timeevent.workItemId.The agent itself fired correctly; only the dashboard webhook log was affected.
Fix
New
resolveWorkItemLabel(result, event)helper picks the most specific label:Both the
Coalesced dispatch scheduledandJob queuedbuild sites inwebhook-processor.tsuse it.Test plan
webhook-processor.test.tscovering the result-over-event preference and the prNumber fallback.npm run lintclean.npm run typecheckclean.🤖 Generated with Claude Code