2 Commits

Author	SHA1	Message	Date
clawbot	13de7cd290	Allow retention_days of 0 to mean retain forever (closes #79) ... RetentionDays carried gorm:"default:30", so GORM substituted 30 for a zero value while building the insert. A webhook could therefore never be configured to keep its events indefinitely: the reaper's retain-forever branch existed but was unreachable from the normal create and edit flows. Introduce database.RetentionForeverDays = 365 * 1000 as the sentinel for "retain forever" and a Webhook.BeforeSave hook that rewrites any non-positive RetentionDays to it. The rewrite has to live in the hook rather than at the call sites: GORM applies the column default while converting the model to insert values, which happens after BeforeSave, so anything later loses that race. Putting it on the model also means a future call site, such as the planned REST API, cannot bypass it. The reaper now skips a webhook when Webhook.RetainsForever reports true, which recognises the sentinel and keeps honouring the old <= 0 values for rows written before it existed. Without this the sentinel, being positive, would have produced a cutoff a thousand years in the past and a DELETE matching nothing on every sweep. Bound the finite retention range, which was previously unbounded on the server. The reaper computes its cutoff as a time.Duration, an int64 nanosecond count, so a day count above 106751 overflows, wraps the span negative, and moves the cutoff into the far future — where it matches every row and the sweep deletes every event, delivery, and delivery result the webhook has, including ones created seconds ago. Nothing rejected such a value: parseRetention accepted any v > 0, and max="365" was a client-side attribute a direct POST ignored, so the wipe was already reachable on main and removing that attribute would have made it reachable by ordinary use. The bound is database.MaxFiniteRetentionDays, derived from the arithmetic itself as math.MaxInt64 / time.Hour / hoursPerDay rather than picked as a round number, and a finite value above it is now a 400 that names the ceiling. retentionCutoff additionally clamps the day count it is given and reports whether any cutoff applies at all, so a row written by an older version, a migration, or a future call site cannot reach the overflow either. A value at or above the retain-forever sentinel stays accepted, because that is what the edit form pre-fills for a retain-forever webhook. Form handling is shared by create and edit through parseRetentionDays so the two cannot drift: an empty field keeps the previous behaviour (default on create, unchanged on edit), 0 is honoured, and an unparseable, negative, or out-of-range value is a 400 that re-renders the form rather than a silently substituted default. The two rejection reasons are distinct sentinel errors so the message can name the ceiling, and the create form now carries the submitted name and description back into the re-rendered inputs, which the edit form already did. The retention inputs drop max="365". That cap was not cosmetic: the edit form pre-fills the stored value, so a retain-forever webhook rendered 365000 into an input capped at 365 and browser validation would have blocked saving any edit to it. min becomes 0 with a hint explaining what 0 does, and the list and detail views render a RetentionLabel of "forever" instead of a raw day count. All three Webhook methods take pointer receivers, so there is no receiver mix and no lint suppression: BeforeSave must take a pointer to mutate the record, and the handlers hand templates a *Webhook because html/template cannot call a pointer method on a value held in a map. The 30-day default is consolidated into database.DefaultRetentionDays, referenced from the handler and from the create form's pre-filled value, with a test asserting it agrees with the struct tag that cannot reference it.	2026-08-09 02:57:28 +00:00
clawbot	7f8469a0f2	feat: implement core webhook engine, delivery system, and management UI (Phase 2) ... - Webhook reception handler: look up entrypoint by UUID, verify active, capture full HTTP request (method, headers, body, content-type), create Event record, queue Delivery records for each active Target, return 200 OK. Handles edge cases: unknown UUID → 404, inactive → 410, oversized → 413. - Delivery engine (internal/delivery): fx-managed background goroutine that polls for pending/retrying deliveries and dispatches to target type handlers. Graceful shutdown via context cancellation. - Target type implementations: - HTTP: fire-and-forget POST with original headers forwarding - Retry: exponential backoff (1s, 2s, 4s...) up to max_retries - Database: immediate success (event already stored) - Log: slog output with event details - Webhook management pages with Tailwind CSS + Alpine.js: - List (/sources): webhooks with entrypoint/target/event counts - Create (/sources/new): form with auto-created default entrypoint - Detail (/source/{id}): config, entrypoints, targets, recent events - Edit (/source/{id}/edit): name, description, retention_days - Delete (/source/{id}/delete): soft-delete with child records - Add Entrypoint (/source/{id}/entrypoints): inline form - Add Target (/source/{id}/targets): type-aware form - Event Log (/source/{id}/logs): paginated with delivery status - Updated README: marked completed items, updated naming conventions table, added delivery engine to package layout and DI docs, updated column names to reflect entity rename. - Rebuilt Tailwind CSS for new template classes. Part of: #15	2026-03-01 16:14:28 -08:00