sneak/webhooker
1
0
Fork 0
Code Issues 13 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Implement the log delivery target #70

New Issue
Closed
opened 2026-08-07 13:16:13 +02:00 by clawbot · 2 comments
clawbot commented 2026-08-07 13:16:13 +02:00
Collaborator
Copy Link

Part of the road to 1.0 (see #33).

Decision (@sneak, 2026-08-07): the database and log target types are REQUIRED for 1.0 and must be implemented — not hidden. Offering the UI options is correct; they must do real work by 1.0.

  • The database target (archiving to a separate per-webhook sqlite file, configurable expiry, close/reopen with a 1s debounce, auto-recreate) is tracked in #43.
  • This issue now covers the log target: deliverLog() (internal/delivery/engine.go) currently only emits a single log line.

Definition of done:

  • the log target writes a structured log entry for each delivered event (at minimum: event id, webhook/entrypoint, target name, and outcome) and marks the delivery delivered
  • behaviour is covered by a test

If the intended log-target semantics differ from the above, that is a quick call to confirm — otherwise the structured-line behaviour is the default.

(Supersedes the earlier "hide the no-op options" framing, which is rejected per the decision above.)

Part of the road to 1.0 (see #33). Decision (@sneak, 2026-08-07): the `database` and `log` target types are REQUIRED for 1.0 and must be **implemented** — not hidden. Offering the UI options is correct; they must do real work by 1.0. - The **database** target (archiving to a separate per-webhook sqlite file, configurable expiry, close/reopen with a 1s debounce, auto-recreate) is tracked in #43. - This issue now covers the **log** target: `deliverLog()` (`internal/delivery/engine.go`) currently only emits a single log line. Definition of done: - the `log` target writes a structured log entry for each delivered event (at minimum: event id, webhook/entrypoint, target name, and outcome) and marks the delivery delivered - behaviour is covered by a test If the intended `log`-target semantics differ from the above, that is a quick call to confirm — otherwise the structured-line behaviour is the default. (Supersedes the earlier "hide the no-op options" framing, which is rejected per the decision above.)
clawbot added this to the 1.0.0 milestone 2026-08-07 13:16:13 +02:00
clawbot changed title from Do not ship selectable no-op database/log delivery target types to Implement the log delivery target 2026-08-07 13:20:21 +02:00
clawbot commented 2026-08-07 14:06:29 +02:00
Author
Collaborator
Copy Link

Implementation instructions

Confine to internal/delivery/engine.go (the deliverLog path) and a delivery-package test only. Do not touch other packages. The database archiving target is tracked separately in #43 — do NOT implement archiving here.

  • Finalize the log delivery target. Inspect the current deliverLog() in engine.go. Make it write a structured slog entry for each delivered event containing at least: the event id, webhook id, entrypoint id (if available on the task), the target name, and the delivery outcome. Then mark the delivery delivered using the same success bookkeeping the other target types use — mirror how deliverHTTP / deliverSlack record a successful delivery (status and any DeliveryResult) so the log target is a first-class target rather than a silent no-op.
  • Use the engine's existing logger and the existing delivery-result/status handling; do not invent a parallel mechanism.

Definition of done:

  • delivering to a log target emits a structured log line with the fields above and records the delivery as delivered (with a DeliveryResult if that is how the other targets record success)
  • a delivery-package test asserts a log target delivery is marked delivered and produces the expected result/status

Gates and process:

  • make fmt; validate with docker build . (must exit 0)
  • branch from main named issue-70-log-target; commit subject ends with (closes #70)
  • open a PR (base main) and comment on it with the diff summary and the docker build . result
  • no AI-assistant/tooling references anywhere
## Implementation instructions Confine to `internal/delivery/engine.go` (the `deliverLog` path) and a delivery-package test only. Do not touch other packages. The `database` archiving target is tracked separately in #43 — do NOT implement archiving here. - Finalize the `log` delivery target. Inspect the current `deliverLog()` in `engine.go`. Make it write a structured slog entry for each delivered event containing at least: the event id, webhook id, entrypoint id (if available on the task), the target name, and the delivery outcome. Then mark the delivery delivered using the same success bookkeeping the other target types use — mirror how `deliverHTTP` / `deliverSlack` record a successful delivery (status and any `DeliveryResult`) so the log target is a first-class target rather than a silent no-op. - Use the engine's existing logger and the existing delivery-result/status handling; do not invent a parallel mechanism. Definition of done: - delivering to a `log` target emits a structured log line with the fields above and records the delivery as delivered (with a `DeliveryResult` if that is how the other targets record success) - a delivery-package test asserts a `log` target delivery is marked delivered and produces the expected result/status Gates and process: - `make fmt`; validate with `docker build .` (must exit 0) - branch from `main` named `issue-70-log-target`; commit subject ends with ` (closes #70)` - open a PR (base `main`) and comment on it with the diff summary and the `docker build .` result - no AI-assistant/tooling references anywhere
clawbot commented 2026-08-07 15:26:45 +02:00
Author
Collaborator
Copy Link

Folded into #77 (Refactor delivery targets to a Target interface). The log target is being reimplemented there as logTarget, including the full inbound body + headers logging @sneak asked for. Closing as superseded; #77 delivers it.

Folded into #77 (Refactor delivery targets to a `Target` interface). The `log` target is being reimplemented there as `logTarget`, including the full inbound body + headers logging @sneak asked for. Closing as superseded; #77 delivers it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
merge-ready
needs-checks
needs-rebase
needs-review
needs-rework
No Label
Milestone
No items
No Milestone 1.0.0
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/webhooker#70
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?