An admin redelivers a failed webhook delivery from the terminal's Deliveries screen with `r` #8084

An admin can now press r on a failed row in the terminal's Deliveries screen to send that delivery again. The new redeliver tests, the existing deliveries and webhooks tests, bun x tsc --noEmit, scripts/gate.ts, scripts/design-lint.ts and test/mcp-size.test.ts all pass here. scripts/fast.ts found the diff too broad to name tests, so I ran the covering test files myself rather than the full suite.

• Core: redeliver(db, deliveryId, webhookId) in src/core/webhooks.ts moves a failed delivery of that hook back to pending, so deliverDue sends it on its next pass. Attempts are reset to 0 and the claim, last status and last error are cleared. It reuses the same row, so there is no new row and no new event.
• What it refuses: a pending or ok delivery gives not_failed, and an unknown id or another hook's gives not_found. A sealed report's delivery gives sealed. In every case nothing changes.
• Racing the worker: a delivery a sender has claimed is pending, so the update, which only matches failed rows, cannot reset it under the sender.
• Terminal: r "redeliver" appears on the Deliveries screen and is disabled unless the selected row is failed. Pressing it shows the toast queued again and the row reads pending. The screen already closes when the user loses admin, so r is only reachable by someone who may manage the hook.
• Tests: test/webhook-redeliver.test.ts covers failed → pending, the refusals and the sealed case. test/tui-hooks-deliveries.test.ts drives r on a failed row and on an ok row.
• Left alone: the API, MCP, docs/MCP.md and the web button.
• One choice to check: I clear the last status and error on redelivery, so the old failure reason disappears from the row once it is queued again. Say if you would rather keep it until the next attempt.

To try it, open Webhooks in the terminal, press Enter on a hook whose delivery failed, then press r on the failed row.

Closes #8075

An admin can now press r on a failed row in the terminal's Deliveries screen to send that delivery again. The new redeliver tests, the existing deliveries and webhooks tests, bun x tsc --noEmit, scripts/gate.ts, scripts/design-lint.ts and test/mcp-size.test.ts all pass here. scripts/fast.ts found the diff too broad to name tests, so I ran the covering test files myself rather than the full suite.

• Core: redeliver(db, deliveryId, webhookId) in src/core/webhooks.ts moves a failed delivery of that hook back to pending, so deliverDue sends it on its next pass. Attempts are reset to 0 and the claim, last status and last error are cleared. It reuses the same row, so there is no new row and no new event.
• What it refuses: a pending or ok delivery gives not_failed, and an unknown id or another hook's gives not_found. A sealed report's delivery gives sealed. In every case nothing changes.
• Racing the worker: a delivery a sender has claimed is pending, so the update, which only matches failed rows, cannot reset it under the sender.
• Terminal: r "redeliver" appears on the Deliveries screen and is disabled unless the selected row is failed. Pressing it shows the toast queued again and the row reads pending. The screen already closes when the user loses admin, so r is only reachable by someone who may manage the hook.
• Tests: test/webhook-redeliver.test.ts covers failed → pending, the refusals and the sealed case. test/tui-hooks-deliveries.test.ts drives r on a failed row and on an ok row.
• Left alone: the API, MCP, docs/MCP.md and the web button.
• One choice to check: I clear the last status and error on redelivery, so the old failure reason disappears from the row once it is queued again. Say if you would rather keep it until the next attempt.

To try it, open Webhooks in the terminal, press Enter on a hook whose delivery failed, then press r on the failed row.

I addressed all five points except the unreadable-payload test, and pushed the changes to the same branch. tsc and the two covering test files (test/webhook-redeliver.test.ts and test/tui-hooks-deliveries.test.ts) pass. The first bun scripts/gate.ts and tsc run printed nothing before the failing test, so I take both as clean. I did not run the full suite; the forge's check does that. Nothing was exercised through the terminal itself.

1. Pipeline-first. I did not hold this. The work was assigned to me as #8075, and I can't argue the ordering against the pipeline list (#6534, #6611, #5276, #3316, #6217, #6428, #1242, #1073). The change is small: one core function, one key, no new surface. If you want it held until the pipeline work lands, say so and I'll leave it unmerged.
2. Both doors. I kept it terminal-only, as the issue asked. The README now documents r on a failed Deliveries row. docs/MCP.md says there is no redeliver action on the hooks tool. There is no web button because the web's deliveries view is read-only. Adding a web or MCP door would be a separate issue.
3. Header comment. I rewrapped it in src/tui/screens/hooks.ts.
4. Tests. The r-on-ok test now also checks that the delivery rows in the database are unchanged. A new test covers a person who lost admin pressing r: nothing queues, and the row stays failed.
5. Sealed check. redeliver now does the read, the sealed check and the update in one immediate transaction, so a report sealed in between cannot slip through. The single-statement UPDATE guard against the worker is unchanged.

Disagreement. You asked for a test that an unreadable payload counts as not sealed, and I couldn't write one. The event table's JSON check rejects a malformed payload at UPDATE (SQLite: "malformed JSON"), so that branch can't be reached through data. I reworded the catch comment to say an unreadable payload counts as not sealed and that the branch can't be reached. I would rather leave that catch untested than add a test that can't fail.

The check failed because I had edited a row of the docs/MCP.md tool table by hand, and that table is generated from the tool files. I put the row back to its generated text and moved the note below the table, outside the generated block. It now says redeliver is only the terminal's r on the Deliveries screen and that the hooks tool has no action for it yet.

bun scripts/mcp-tools.ts reports the table as current, and test/mcp-tools.test.ts passes (173 tests). I did not re-run the full suite; the forge's check does that on this push.

The rest of the pull is unchanged from the earlier round:

• redeliver reads, checks for a sealed report and updates in one transaction.
• The README documents r.
• The tests cover a non-admin pressing r and the database row staying unchanged.
• The unreadable-payload branch has no test, because the event table's JSON check makes it unreachable.
• I did not hold this behind the pipeline-first list, and terminal-only was the issue's ask.

In the terminal, a repository admin can now press r on a failed row of a hook's Deliveries screen to send that delivery again. redeliver in src/core/webhooks.ts resets the same row to pending: attempts go back to zero, the claim and the last status and error are cleared, and no new row or event is made. The worker then picks it up on its next pass. The read, the sealed-report check and the update run in one immediate transaction. So r does nothing on a row that is not failed, and a sealed report's delivery stays refused.

The how-to is now in its own file, docs/features/webhook-redeliver.md. It covers the key, which rows it works on, the attempt reset, the sealed-report refusal and that it is terminal-only for now. The README hunk is reverted, so README.md matches main. The terminal-only note stays in docs/MCP.md, below the generated tool table.

There is no page button or MCP action yet. The issue asked for the terminal, and the read-only deliveries list on the web has no control to put a button on.

Tests: test/webhook-redeliver.test.ts covers the core function, including a non-admin being refused and the database row left unchanged on a refusal. test/tui-hooks-deliveries.test.ts covers the key on the screen. On this last push, bun scripts/gate.ts, bun x tsc --noEmit, test/readme-cap.test.ts and test/mcp-docs.test.ts pass. I did not run the preview, because the change is terminal-only.

To try it: open a hook's Deliveries screen in the terminal as a repository admin, move to a failed row and press r. The row shows pending, and then delivered or failed once the worker has tried it.

🤖 Generated with Claude Code

In the terminal, a repository admin can now press r on a failed row of a hook's Deliveries screen to send that delivery again. redeliver in src/core/webhooks.ts resets the same row to pending: attempts go back to zero, the claim and the last status and error are cleared, and no new row or event is made. The worker then picks it up on its next pass. The read, the sealed-report check and the update run in one immediate transaction. So r does nothing on a row that is not failed, and a sealed report's delivery stays refused. The how-to is in docs/features/webhook-redeliver.md, and the terminal-only note is in docs/MCP.md; README.md is unchanged.

This push merges main, which added p to pause or resume a hook. The only conflict was the header comment of src/tui/screens/hooks.ts, which now describes both r and p. The worker skips the pending rows of a paused hook, so a delivery redelivered on a paused hook waits until the hook is resumed; the feature doc now says so.

There is no page button or MCP action yet. The issue asked for the terminal, and the read-only deliveries list on the web has no control to put a button on.

After the merge, bun scripts/gate.ts, bun x tsc --noEmit and the hook and webhook test files (test/webhook-redeliver.test.ts, test/tui-hooks-deliveries.test.ts and the other tui-hooks*/webhook* files) pass: 33 pass, 0 fail. I did not run the preview, because the change is terminal-only.

To try it: open a hook's Deliveries screen in the terminal as a repository admin, move to a failed row and press r. The row shows pending, and then delivered or failed once the worker has tried it.

🤖 Generated with Claude Code

The full-suite proof of this head is waiting: no check slot is spare. It starts when one frees.

In the terminal, a repository admin can now press r on a failed row of a hook's Deliveries screen to send that delivery again. redeliver in src/core/webhooks.ts resets the same row to pending: attempts go back to zero, the claim and the last status and error are cleared, and no new row or event is made. The worker then picks it up on its next pass. The read, the sealed-report check and the update run in one immediate transaction. So r does nothing on a row that is not failed, and a sealed report's delivery stays refused. On a paused hook the row stays pending until the hook is resumed.

The how-to is in docs/features/webhook-redeliver.md, and the terminal-only note is in docs/MCP.md below the generated tool table; README.md is unchanged. Merging main, which added p to pause or resume a hook, only touched the header comment of src/tui/screens/hooks.ts, which now describes both keys.

There is no page button or MCP action yet. The issue asked for the terminal, and the read-only deliveries list on the web has no control to put a button on. The feature is not on the pipeline-first list; it goes ahead because the issue asked for this terminal action on its own.

This round's review raised nothing to change, so the head stays at 07f38b8d. The branch matches origin and still merges cleanly into main. The full-suite check of this head is queued until a check slot frees.

At 07f38b8d, bun scripts/gate.ts, bun x tsc --noEmit and the hook and webhook test files (test/webhook-redeliver.test.ts, test/tui-hooks-deliveries.test.ts and the other tui-hooks*/webhook* files) passed: 33 pass, 0 fail. I did not run the preview, because the change is terminal-only.

To try it: open a hook's Deliveries screen in the terminal as a repository admin, move to a failed row and press r. The row shows pending, and then delivered or failed once the worker has tried it.

🤖 Generated with Claude Code