delivery_results stores status_code, response_body, error, duration and attempt_num, and no template renders any of it. A grep of templates/ finds no StatusCode, ResponseBody or Attempt. The event log renders only {{.Target.Name}}: {{.Status}} (templates/source_logs.html:26-30), so a failure reads echo-sink: failed and nothing else.
Diagnosing why a delivery failed currently requires opening the per-webhook SQLite file by hand. For a store-and-forward proxy that is the first question an operator asks, so this is a 1.0 gap rather than a polish item.
Related but distinct: #107 covers terminal-state correctness in the engine. This issue is purely the read path.
Definition of done:
expanding a delivery on the source detail / event log page shows, per attempt: attempt number, status code, duration, the error string, and the response body
the response body is bounded in the query the same way event bodies are (see #135), not read whole and truncated in Go
a handler test asserts a failed delivery's status code and error reach the rendered page
`delivery_results` stores `status_code`, `response_body`, `error`, `duration` and `attempt_num`, and no template renders any of it. A grep of `templates/` finds no `StatusCode`, `ResponseBody` or `Attempt`. The event log renders only `{{.Target.Name}}: {{.Status}}` (`templates/source_logs.html:26-30`), so a failure reads `echo-sink: failed` and nothing else.
Diagnosing why a delivery failed currently requires opening the per-webhook SQLite file by hand. For a store-and-forward proxy that is the first question an operator asks, so this is a 1.0 gap rather than a polish item.
Related but distinct: #107 covers terminal-state correctness in the engine. This issue is purely the read path.
Definition of done:
- expanding a delivery on the source detail / event log page shows, per attempt: attempt number, status code, duration, the error string, and the response body
- the response body is bounded in the query the same way event bodies are (see #135), not read whole and truncated in Go
- target config and any credential-bearing field stay masked, consistent with #113, #115 and #118
- a handler test asserts a failed delivery's status code and error reach the rendered page
clawbot
added this to the 1.0.0 milestone 2026-08-20 05:47:14 +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.
delivery_resultsstoresstatus_code,response_body,error,durationandattempt_num, and no template renders any of it. A grep oftemplates/finds noStatusCode,ResponseBodyorAttempt. The event log renders only{{.Target.Name}}: {{.Status}}(templates/source_logs.html:26-30), so a failure readsecho-sink: failedand nothing else.Diagnosing why a delivery failed currently requires opening the per-webhook SQLite file by hand. For a store-and-forward proxy that is the first question an operator asks, so this is a 1.0 gap rather than a polish item.
Related but distinct: #107 covers terminal-state correctness in the engine. This issue is purely the read path.
Definition of done:
clawbot referenced this issue2026-08-20 05:56:52 +02:00