Commit Graph

2 Commits

Author SHA1 Message Date
f3cb56345f Resubmit a stored event as a new undelivered event (closes #250)
All checks were successful
check / check (push) Successful in 3m3s
Capturing real webhook traffic and firing it repeatedly at a backend
under development is a primary function of this service, and
per-delivery replay cannot do it: it only ever resolves the delivery's
own original target, so a target created for a dev backend has no
prior delivery and nothing can be replayed to it.

The event log now offers a per-event Resubmit action. It stores a NEW
event copying the stored one's method, headers, body and content type
verbatim, and fans it out to the webhook's currently ACTIVE targets,
resolved fresh by the query the receiver uses -- so a target created
long after the original event arrived receives it. The original
event's deliveries have no bearing on where the copy goes, inactive
targets are skipped as the receiver skips them, and the action is
repeatable: replay's in-flight refusal is deliberately not ported,
because firing one captured event over and over is the point.

The receiver and the resubmit path share one construction and one
fan-out site. An eventSource value carries where the fields came from,
live request or stored event, and createAndFanOut writes the event and
its pending deliveries in one transaction and hands the tasks to the
same Notifier, so a resubmitted delivery is retried, SSRF-guarded and
circuit-broken exactly as a first one is. buildDeliveryTasks returns
an error instead of writing a response, which is what lets both
callers share it.

The stored event is read once, before the write transaction, with a
cast to blob, so a body over delivery.MaxInlineBodySize is copied byte
for byte and the engine loads it from the new event row.

A nullable resubmitted_from_id records provenance -- empty for an
event that arrived on the receiver -- and the event log reports the
relationship in both directions, without which the log is unreadable
after a few resubmits of one event. The route sits in the owned-source
group, so auth, CSRF and the body cap apply, with its own rate limit
bucket and an events_resubmitted_total counter.

Inbound signature verification is not re-run: there is no inbound
signature to check on a copy an authenticated, CSRF-protected operator
action submits.

Per-delivery replay is unchanged; it serves recovery, which resubmit
does not replace. The README claimed in four places that replay was
unimplemented, one of them telling the operator that a delivery
stranded by a target type change was lost; all four are corrected and
resubmit is documented beside replay.
2026-08-23 22:38:10 +00:00
279effb4c2 Bound the event log's rendered bodies in the query (closes #135)
All checks were successful
check / check (push) Successful in 3m0s
The event log rendered stored bodies untruncated. Since buffered
rendering landed (#123) that became resident memory per concurrent
viewer, up to tens of MB, driven by payloads unauthenticated clients
supply to the public receiver.

Bound in the query rather than the template, via
substr(cast(body as blob), 1, ?) plus length(cast(body as blob)), so an
oversized body never becomes a Go string at all. Adds an EventLogView
projection carrying the true byte count, and trims a partial UTF-8 tail
without rewriting bodies that are merely invalid UTF-8.

Independently reviewed. The generated SQL was dumped under GORM DryRun
to confirm the cap is a bound parameter, both casts are present, and no
other path selects the full column; soft-delete scope, ordering and
pagination are unchanged.

Correction to the PR body: its quoted mutation output was produced by
removing the bound from eventLogColumns, not by raising the cap to
1<<30 as the text claimed. The reviewer reproduced the real
mutation and confirmed the tests do catch removal of the bound.

Follow-up #157 restores in-app retrieval of bodies above the cap.
2026-08-17 22:57:08 +02:00