Change. Two methods on the delivery engine take over the write path from the handlers. The first stores an event with one pending delivery per active target and the totals, in one transaction, then queues those deliveries. The second creates one more delivery of a stored event (replay) and queues it. The receiver, resubmit and replay handlers parse the request and make one call. The handlers depend on the engine itself; the Notifier, Archives and CircuitBreakers interfaces and their three bridge functions in cmd/webhooker/main.go go wherever nothing else needs them.
Why. The write path that defines the product lives in the HTTP package and is written twice: fan-out in createAndFanOut, a single delivery in createReplayDelivery. The engine, which owns deliveries everywhere else, learns of them through a Notifier carrying copies. With the two methods, the totals bookkeeping has one home and a handler is request parsing plus one call.
Not part of this. Delivery tasks keep carrying their copies of the event and the target; making a task carry only identifiers was not approved.
What it touches.internal/handlers/webhook.go (eventSource, createAndFanOut, buildDeliveryTasks, inlineBody), event_resubmit.go (queueResubmit), delivery_replay.go (createReplayDelivery, replayBody), handlers.go; internal/delivery/engine.go (Notifier, Archives, CircuitBreakers); cmd/webhooker/main.go; the README's Request Flow and Dependency Injection sections.
Definition of done. The receiver, resubmit and replay handlers write no event, delivery or totals rows; the engine's two methods are the only code that creates deliveries. The receiver answers exactly as today (status codes, bodies, size limit, rate limits). Tests cover each handler path and each engine method, including the transaction rolling back when a write fails. The README matches.
Builds last of the approved changes: after #542, #543 and #534, which change the same files.
Model: opus-5-5
Approved by sneak on https://git.eeqj.de/sneak/webhooker/issues/499#issuecomment-142500.
**Change.** Two methods on the delivery engine take over the write path from the handlers. The first stores an event with one `pending` delivery per active target and the totals, in one transaction, then queues those deliveries. The second creates one more delivery of a stored event (replay) and queues it. The receiver, resubmit and replay handlers parse the request and make one call. The handlers depend on the engine itself; the `Notifier`, `Archives` and `CircuitBreakers` interfaces and their three bridge functions in `cmd/webhooker/main.go` go wherever nothing else needs them.
**Why.** The write path that defines the product lives in the HTTP package and is written twice: fan-out in `createAndFanOut`, a single delivery in `createReplayDelivery`. The engine, which owns deliveries everywhere else, learns of them through a `Notifier` carrying copies. With the two methods, the totals bookkeeping has one home and a handler is request parsing plus one call.
**Not part of this.** Delivery tasks keep carrying their copies of the event and the target; making a task carry only identifiers was not approved.
**What it touches.** `internal/handlers/webhook.go` (`eventSource`, `createAndFanOut`, `buildDeliveryTasks`, `inlineBody`), `event_resubmit.go` (`queueResubmit`), `delivery_replay.go` (`createReplayDelivery`, `replayBody`), `handlers.go`; `internal/delivery/engine.go` (`Notifier`, `Archives`, `CircuitBreakers`); `cmd/webhooker/main.go`; the README's Request Flow and Dependency Injection sections.
**Definition of done.** The receiver, resubmit and replay handlers write no event, delivery or totals rows; the engine's two methods are the only code that creates deliveries. The receiver answers exactly as today (status codes, bodies, size limit, rate limits). Tests cover each handler path and each engine method, including the transaction rolling back when a write fails. The README matches.
Builds last of the approved changes: after https://git.eeqj.de/sneak/webhooker/issues/542, https://git.eeqj.de/sneak/webhooker/issues/543 and https://git.eeqj.de/sneak/webhooker/pulls/534, which change the same files.
Model: opus-5-5
clawbot
self-assigned this 2026-10-15 11:57:20 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Approved by sneak on #499 (comment).
Change. Two methods on the delivery engine take over the write path from the handlers. The first stores an event with one
pendingdelivery per active target and the totals, in one transaction, then queues those deliveries. The second creates one more delivery of a stored event (replay) and queues it. The receiver, resubmit and replay handlers parse the request and make one call. The handlers depend on the engine itself; theNotifier,ArchivesandCircuitBreakersinterfaces and their three bridge functions incmd/webhooker/main.gogo wherever nothing else needs them.Why. The write path that defines the product lives in the HTTP package and is written twice: fan-out in
createAndFanOut, a single delivery increateReplayDelivery. The engine, which owns deliveries everywhere else, learns of them through aNotifiercarrying copies. With the two methods, the totals bookkeeping has one home and a handler is request parsing plus one call.Not part of this. Delivery tasks keep carrying their copies of the event and the target; making a task carry only identifiers was not approved.
What it touches.
internal/handlers/webhook.go(eventSource,createAndFanOut,buildDeliveryTasks,inlineBody),event_resubmit.go(queueResubmit),delivery_replay.go(createReplayDelivery,replayBody),handlers.go;internal/delivery/engine.go(Notifier,Archives,CircuitBreakers);cmd/webhooker/main.go; the README's Request Flow and Dependency Injection sections.Definition of done. The receiver, resubmit and replay handlers write no event, delivery or totals rows; the engine's two methods are the only code that creates deliveries. The receiver answers exactly as today (status codes, bodies, size limit, rate limits). Tests cover each handler path and each engine method, including the transaction rolling back when a write fails. The README matches.
Builds last of the approved changes: after #542, #543 and #534, which change the same files.
Model: opus-5-5