fix(task-board): resolve the review sweeper's in-progress lane from the board - #6858
Merged
Merged
Conversation
decocms Bot
pushed a commit
that referenced
this pull request
Sep 2, 2026
PR: #6858 fix(task-board): resolve the review sweeper's in-progress lane from the board Bump type: patch - decocms (apps/api/package.json): 4.319.1 -> 4.319.2 - @decocms/native (apps/native/package.json): 4.319.1 -> 4.319.2 Deploy-Scope: server
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
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.
Follows #6790 ("every lane decision goes through the board, not a literal") and #6854, which fixed the same bug pattern elsewhere in the task-board reactions but missed this file.
TaskBoardReviewSweeper.dispatchDueRetriesand.returnToTodoinreview-sweeper.tscompareditem.statusagainst the hardcoded literal"in_progress"instead of asking the board which column means "in progress" (boardLanesForDb(...).progress). For an org onorg_board_columns(a board mirrored from a tracker, e.g. Jira), the in-progress column has a different key — sodispatchDueRetrieswould silently skip every due infrastructure retry it scanned (the re-read guard would always readitem.status !== lanes.progressas true andcontinue), andreturnToTodowould never park a permanently-failed card back on To Do. Both fail silently: no error, no log, the card just never recovers.Fix: read
lanes.progressfrom the board via the existingboardLanesForDbcall (already present inreturnToTodo; added todispatchDueRetries) and compare against that instead of the literal.Failure scenario: an org-owned board whose in-progress column key isn't literally
"in_progress"has a Super Agent task fail with a transient/infrastructure error.reactToFailedTaskRunschedules a retry correctly (it already goes throughlanes.progress), but the sweeper'sdispatchDueRetriesnever re-dispatches it — the card sits stuck forever with no visible error, and a permanently-failed one never gets parked back on To Do for a human either.Reviewer:
bun run fmt,cd apps/api && bunx tsc --noEmit,bunx oxlint src/tools/task-board/review-sweeper.tsall pass. No existing pure-function unit test covers this (both methods need a live board handle from Postgres), so I didn't add one rather than fake a DB — full CI's integration tier is the right place to catch a regression here.Locally verified: fmt, targeted tsc, targeted oxlint. Full CI runs the rest.
Summary by cubic
Fixes the review sweeper to compare against the board's actual in-progress lane instead of the hardcoded
"in_progress"status. Previously, on orgs with custom board columns (e.g., mirrored from Jira), due retries were silently skipped and permanently-failed cards were never parked back on To Do.Written for commit fd54e7f. Summary will update on new commits.