1 Commits
Author SHA1 Message Date
sneak eacf1e7926 next into main (#556)
check / check (push) Canceled after 0s
Reviewed-on: #556
2026-10-25 02:52:09 +01:00
+44 -40
View File
@@ -1,68 +1,72 @@
# Workflow # Workflow
One issue per unit of work, and one branch and one PR per issue: One issue per unit of work, one branch and one PR per issue:
- make sure a tracked issue exists with a definition of done - ensure a tracked issue exists with a definition of done
- branch from `next`, never from `main` - branch from `next` (never from `main`)
- do the work, then open a PR with base `next`, never `main` - do the work; open a PR based on `next` (never on `main`)
- pass an independent review; the manager then squash-merges into `next` - pass an independent review, then the manager squash-merges into `next`
- push; nothing stays local-only - push; nothing stays local-only
`next` is the branch for the next milestone. It must stay green and mergeable `next` is the branch for the next milestone and must stay green and mergeable to
into `main` at all times. One PR from `next` into `main` accumulates the `main` without notice. One `next` -> `main` PR accumulates the milestone;
milestone. Releases are cut from `main` separately. releases are cut from `main` separately.
The tracker (https://git.eeqj.de/sneak/webhooker/issues) records what is done The tracker (https://git.eeqj.de/sneak/webhooker/issues) is the record of what
and what is under way. This file keeps no list of either. is done and what is under way. This file keeps no list of either.
# Status # Status
What is still open for 1.0.0 is in its milestone What is still open for 1.0.0 is in its milestone
(https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged. Only (https://git.eeqj.de/sneak/webhooker/milestone/9). `v1.0.0` is not tagged, and
@sneak tags it. only @sneak tags it.
Delivery is at least once by design. A send whose result row does not land is Delivery is at-least-once by design, not by accident: a send whose result row
sent again, so a receiver can see a duplicate. The alternative is a silent lost does not land is attempted again, so a receiver can see a duplicate. That is
delivery. The README says so under How it works. It is not a defect to re-file. deliberate — the alternative is a silent lost delivery — and the README says so
under Rationale. It is not a defect to re-file.
# Next Step # Next Step
@sneak runs webhooker in limited production, then tags `v1.0.0`. Merging `next` @sneak runs webhooker in limited production, then tags `v1.0.0`. Merging `next`
into `main` is a separate act from tagging and waits on neither. `next` is kept into `main` is a separate act from tagging and waits on neither of those: `next`
mergeable at all times; that is the point of the branch. is kept mergeable at all times, which is the point of the branch.
# Future Steps # Future Steps
- Per-webhook rate limits, set in the web UI and enforced in the receiver. Today - Per-webhook rate limits, set in the web UI and enforced in the receiver
`RECEIVER_RATE_LIMIT` sets one limit for every entrypoint on the server. handler, on top of the receiver's existing limits, which `RECEIVER_RATE_LIMIT`
- API key authentication for programmatic access. The `APIKey` table exists, but sets for the whole server (see Rate Limiting in the README)
nothing creates a key and nothing checks one. - API key authentication for programmatic access (the `APIKey` model exists, but
- REST API v1. `/api/v1` is mounted with no routes today. nothing creates a key and no middleware checks one)
- CRUD for webhooks, entrypoints and targets - REST API v1
- CRUD for webhooks, entrypoints, targets
- event viewing and filtering endpoints - event viewing and filtering endpoints
- event redelivery endpoint - event redelivery endpoint
- OpenAPI specification - OpenAPI specification
- Analytics in the web UI: response times summarised per webhook or per target, - Analytics in the web UI: response times summarised per webhook or per target,
and figures for all webhooks together. Today the webhook page shows event, and figures for all webhooks together. The webhook page already shows event,
delivery and failure counts and failure percentages. The target list counts delivery and failure counts and failure percentages, the target list counts
each target's deliveries. The event log shows every attempt's duration. each target's deliveries, the event log and each event's page show every
`/metrics` carries server-wide counts and delivery durations. attempt's duration, and `/metrics` carries server-wide counts and delivery
- A remember-me option at login. Today every session survives a browser restart. durations
It lasts up to 7 days, and ends sooner after `SESSION_IDLE_TIMEOUT` (default - A remember-me option at login. Every session already survives a browser
24 hours) without use. restart: it lasts up to 7 days, and ends sooner after `SESSION_IDLE_TIMEOUT`
- Password reset over the web for a forgotten password. Today a signed-in user (default 24 hours) without activity
can change their password, and a lost password is reset from the console with - Password reset flow for a forgotten password over the web. The authenticated
`webhooker resetpw` (https://git.eeqj.de/sneak/webhooker/issues/208). password _change_ flow already landed, and a lost password is recoverable from
the console with `webhooker resetpw`
(https://git.eeqj.de/sneak/webhooker/issues/208)
- Later, nice to have - Later, nice to have
- email delivery target type - email delivery target type
- SNS and S3 delivery targets - SNS and S3 delivery targets
- data transformations, such as a configurable Slack message format; the - data transformations (e.g. a configurable Slack message format; the Slack
Slack target sends one fixed format today target sends one fixed format today)
- JSONL file delivery with periodic S3 upload. Today the `database` target - JSONL file delivery with periodic S3 upload (the `database` target already
archives events to SQLite files, rotated hourly, daily or monthly if set, archives events to SQLite files, rotated hourly, daily or monthly if set,
and the webhook page offers them as one gzipped JSON download. and the webhook page offers them as one gzipped JSON download)
- webhook event search, and filtering beyond the event log's failed and - webhook event search, and filtering beyond the event log's failed and
pending views pending views
- multi-user with role-based access control. Today each webhook belongs to - multi-user with role-based access control (each webhook already belongs to
one account, but only the account made at first boot exists and there is one account, but there is only the account made at first boot and no way
no way to add another. to add another)