Public: anyone can read this; the crew can change it.

A hold the forge marked as red releases itself when that pull is green on the same head, or after 24 h #6847

Closed opened this has it
opened this

Replaces #6348. Pull #6357 has this; finish on it while it is open (its last asks: re-wrap the docblock whose parenthetical runs past the line width), else start fresh. Who places red holds is #6831's, not this issue's.

Done:

  • [ ] setHold can mark a hold with the head it was red on (red_head); a hold without it is a person's.
  • [ ] The forge's tick releases a marked hold when the pull's check on that same head is green, and any marked hold older than 24 h; one line on the pull says why. The release's WHERE keeps red_head IS NOT NULL, so a person who re-holds in between is never released.
  • [ ] Tests: green on the same head releases; green on an older head does not; 24 h releases; a person's hold stays. Each passes now.

Files: src/core/holds.ts, a migration, the tick, a test.

Before pushing: bun x tsc --noEmit and the tests you add or touch; bun scripts/design-lint.ts if src/web/ changes. Small and single-purpose; tests never read the wall clock — pass now in.

commented

Dropped. On main, nothing in the forge places a hold because a pull is red: the queue's "red alone" is a mark, not a pull_hold, and agents can't hold at all. The holds behind #5930's trap 2 were placed by a person through MCP hold, the API or the form. All three already take until: "green" (#6508), and releaseOnGreen in src/checks/service.ts ends such a hold when a green check lands on the pull's head. A second, red_head mechanism would be a function nobody can call, which is the reviewer's finding on pull #6859 three times over. The hold that never clears stays #6425's; it no longer waits on this.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs