Commit Graph
3 Commits
Author SHA1 Message Date
clawbot 2de98cedbe Render admin page errors in the normal layout (closes #382)
check / check (push) Successful in 4m15s
Every 400, 403, 404 and 500 on an admin page now answers with an
error page in the normal layout: one fixed line for the status and a
link back to the webhook list, or to sign-in when nobody is signed
in. The router's handler for unknown paths, the CSRF middleware's
refusal and a panic in an admin page route group use the same page;
each such group has its own recoverer and error reporting for that.
The page always sends Cache-Control: no-store. Status codes are
unchanged. The receiver, the healthcheck and /metrics keep their
plain answers. If the error page cannot render, or panics, the answer
is the same status in plain text.

Model: opus-5-5
2026-10-02 00:21:49 +00:00
clawbot fd5966f807 Validate max_retries on both target forms (closes #221)
check / check (push) Successful in 3m36s
2026-08-24 01:32:48 +02:00
clawbot 3b0ed826bc Add per-delivery replay to the event log (closes #203) (#240)
check / check (push) Successful in 3m21s
There was no redelivery path anywhere: once a delivery exhausted
max_retries it was failed permanently, even though the event body is
durably stored. Storing an event and being unable to re-send it defeats
the reason it is stored, and the ordinary case is a destination that was
down longer than the backoff ladder.

Adds POST /source/{sourceID}/deliveries/{deliveryID}/replay, inside the
authenticated group so it inherits MaxBodySize, CSRF, NoCache and
RequireAuth. Replay creates a NEW pending delivery against the target's
CURRENT config and hands it to the engine through the same notifier the
receiver uses, so it runs the normal path with the retry ladder, the
SSRF-guarded transport and the circuit breaker. The original delivery's
rows are never touched, and the stored event body is re-sent, never the
recorded response.

Replay is refused, with a distinct message, for a non-terminal delivery, a
deleted target, a deactivated target, and when an earlier replay of the
same event and target is still in flight. Bounded by a per-client rate
limit and by that in-flight check.

The new delivery row is written with Omit(clause.Associations) and with
neither Event nor Target populated, so it cannot upsert a targets row into
the per-webhook event database (#206).

Counted by webhooker_delivery_replays_total on the existing target_type
label. A replay also moves the ordinary attempt, outcome and duration
series, because it is a real delivery.
2026-08-20 08:11:35 +02:00