fix(task-board): sweep a settled delivery-lane card into the archive, not just Done - #6983
Closed
pedrofrxncx wants to merge 1 commit into
Closed
fix(task-board): sweep a settled delivery-lane card into the archive, not just Done#6983pedrofrxncx wants to merge 1 commit into
pedrofrxncx wants to merge 1 commit into
Conversation
… not just Done The auto-archive sweep (archive-merged.ts / listItemsAwaitingArchive) still gated on the literal status "done", but shippedLane() sends a delivery-lanes org's shipped cards to "merged"/"post_deploy_validation" instead — they never reach "done" on their own. The merged-tag sweep hit the exact same problem and was already fixed to use the broader TAGGABLE_MERGED_STATUSES/isTaggableMergedStatus set; the archive sweep was left behind on the old literal, so a delivery-lanes org's shipped cards never settle into the archive no matter how old they get. Reused the existing isTaggableMergedStatus (lanes.ts) and TAGGABLE_MERGED_STATUSES (storage/task-board.ts) that tag-merged.ts already established as the correct gate, in both the SQL candidate query and the in-process re-check. Also fixed the activity log recording a hardcoded from: "done" on every auto-archive, which was wrong even before this fix whenever "done" itself wasn't the source lane. Inverted the existing integration test "never sweeps a card resting in a delivery lane" (which encoded the bug as intended behavior) into one asserting a settled delivery-lane card DOES get archived, mirroring the shape of listItemsAwaitingMergedTag's own test. To verify: bun test apps/api/src/tools/task-board/archive-merged.integration.test.ts (needs the real-Postgres test DB; ran the pure archive-merged.test.ts and tsc --noEmit locally, both clean, since this worktree has no Postgres).
Collaborator
Author
|
Closing as stale: this PR sat past the bot's 48h merge window, main has moved on, and its CI results no longer reflect the current base. This is a housekeeping close, not a rejection of the change — if the underlying problem still exists, the bot will find it again and open a fresh, rebased PR. [studio-bot:stale-close] |
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.
What: The auto-archive sweep (
archive-merged.ts/listItemsAwaitingArchive) still gated on the literal status"done", butshippedLane()sends a delivery-lanes org's shipped cards to"merged"/"post_deploy_validation"instead — they never reach"done"on their own (seepackages/shared/src/task-board.ts'sshippedLane). The merged-tag sweep hit the exact same gap and was already fixed to gate on the broaderTAGGABLE_MERGED_STATUSES/isTaggableMergedStatusset (see the comment onlistItemsAwaitingMergedTag), but the archive sweep was left behind on the old literal — so on any org runningdelivery_lanes_enabled, a shipped card never settles into the archive no matter how old it gets.Why a maintainer wants this: the archive sweep is the only thing keeping Done from growing unbounded ("a Done column with 77 cards nobody reads" per its own doc comment); for a delivery-lanes org it currently does nothing at all, and nobody would notice until the board is unusable.
Fix: reused the already-established
isTaggableMergedStatus(lanes.ts) andTAGGABLE_MERGED_STATUSES(storage/task-board.ts) thattag-merged.tsuses for the identical problem, in both the SQL candidate query and the in-process re-check gate. Also fixed the activity log recording a hardcodedfrom: "done"on every auto-archive — now records the card's real prior status, which matters once that status can be a delivery lane.Regression test: inverted the existing integration test
"never sweeps a card resting in a delivery lane"(which asserted the bug as intended behavior, with a misleading comment about lane ordering) into"sweeps a settled card resting in a delivery lane, same as Done", mirroring the shape oflistItemsAwaitingMergedTag's own coverage.To verify:
bun test apps/api/src/tools/task-board/archive-merged.integration.test.ts(needs the real-Postgres test DB — this worktree has none, so I could not run it locally).Checked locally:
bun test apps/api/src/tools/task-board/archive-merged.test.ts(pure logic, unaffected by this change) passes;tsc --noEmitinapps/apiis clean;oxlinton the three touched files is clean;bun run fmtapplied. Full CI (including the real-Postgres integration test) validates the rest.Summary by cubic
The auto-archive sweep now archives settled cards in delivery lanes, not just cards literally in Done.
merged/post_deploy_validationand never reachdone, so the old gate left them unarchived forever.isTaggableMergedStatusandTAGGABLE_MERGED_STATUSESchecks already used by the merged-tag sweep.from: "done".Written for commit bb6b2ec. Summary will update on new commits.