Fix two resubmit comments and test the resubmit route's middleware (closes #252)
check / check (push) Waiting to run
check / check (push) Waiting to run
Two comments named the wrong mechanism: loadResubmitSource credited soft-delete for refusing a reaped event, though the retention reaper deletes event rows outright, and createAndFanOut claimed to be the only path that creates deliveries, though per-delivery replay creates one without an event. Both now say what the code does. The resubmit route's middleware had no tests through the router; new tests drive the production router to pin the refusal without a valid CSRF token, the rate limit, signed-out requests never spending it, and another webhook's event refused by the event lookup while the user's own event is accepted. Each fails with its check removed. Model: opus-5-5
This commit was merged in pull request #457.
This commit is contained in:
@@ -145,8 +145,9 @@ func (h *Handlers) resubmitEvent(
|
||||
// per-webhook database files — a sibling webhook's event is not in the
|
||||
// database being queried at all — and is there so the scoping survives
|
||||
// any future change that puts more than one webhook's events in one
|
||||
// file. Going through Model applies GORM's soft-delete scope, which is
|
||||
// what stops a reaped event being resubmitted.
|
||||
// file. A reaped event is not found because the retention reaper
|
||||
// deletes its row outright rather than marking it deleted; see
|
||||
// deleteEvents in internal/database/retention.go.
|
||||
func loadResubmitSource(
|
||||
webhookDB *gorm.DB,
|
||||
webhookID, eventID string,
|
||||
|
||||
Reference in New Issue
Block a user