Recover GlitchTip-backed host-side ward panic reporting #843

New issue

Closed

opened 2026-07-09 18:26:10 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 18:26:10 +00:00

Member

Context: implementation follow-up from #668. The consult decision is settled: recover the idea from ward-salvage/ward-0d7db064, but re-apply it from current main instead of merging the stale salvage branch.

Scope:

Add host-side ward self-crash reporting through GlitchTip using github.com/getsentry/sentry-go.
Keep phase 1 panic-only or panic-narrow: capture top-level ward Go panics, report, flush, then re-panic so normal failure semantics stay intact.
Make reporting off by default. Resolve the DSN from WARD_SENTRY_DSN, with the operator convention backing it from /sentry-dsn/ward outside this issue.
Reuse ward's existing redaction discipline before sending event data.
Tag release/version, verb, and non-secret runtime context where useful.
Document the feature and the explicit boundary.

Non-goals:

Do not inject a DSN into warded containers.
Do not report agent outcomes, transcripts, issue bodies, or run content to GlitchTip.
Do not revive the salvage branch wholesale or downgrade dependencies from its old go.mod snapshot.
Do not replace SigNoz agent-run telemetry.

Acceptance:

Crash reporting is disabled when no DSN is set.
A test proves panic reporting uses redaction and preserves panic behavior.
Docs describe provider, env var, off-by-default posture, and non-goals.
ward exec test passes.

Closes #668 when landed.

Context: implementation follow-up from #668. The consult decision is settled: recover the idea from `ward-salvage/ward-0d7db064`, but re-apply it from current `main` instead of merging the stale salvage branch. Scope: * Add host-side ward self-crash reporting through GlitchTip using `github.com/getsentry/sentry-go`. * Keep phase 1 panic-only or panic-narrow: capture top-level `ward` Go panics, report, flush, then re-panic so normal failure semantics stay intact. * Make reporting off by default. Resolve the DSN from `WARD_SENTRY_DSN`, with the operator convention backing it from `/sentry-dsn/ward` outside this issue. * Reuse ward's existing redaction discipline before sending event data. * Tag release/version, verb, and non-secret runtime context where useful. * Document the feature and the explicit boundary. Non-goals: * Do not inject a DSN into warded containers. * Do not report agent outcomes, transcripts, issue bodies, or run content to GlitchTip. * Do not revive the salvage branch wholesale or downgrade dependencies from its old `go.mod` snapshot. * Do not replace SigNoz agent-run telemetry. Acceptance: * Crash reporting is disabled when no DSN is set. * A test proves panic reporting uses redaction and preserves panic behavior. * Docs describe provider, env var, off-by-default posture, and non-goals. * `ward exec test` passes. Closes #668 when landed.

coilyco-ops added the

headless

labels

2026-07-09 18:26:10 +00:00

coilyco-ops referenced this issue

2026-07-09 18:26:21 +00:00

Decide ward crash-reporting provider and scope before recovering salvage error reporting #668

coilyco-ops commented

2026-07-09 18:29:20 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-843 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T18:29:18Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#843 · branch issue-843 · harness codex · workflow pull-request
Run: engineer-codex-ward-843 · ward v0.493.0 · dispatched 2026-07-09T18:29:18Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-843` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T18:29:18Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#843` · branch `issue-843` · harness `codex` · workflow `pull-request` - **Run:** `engineer-codex-ward-843` · ward `v0.493.0` · dispatched `2026-07-09T18:29:18Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 18:41:03 +00:00

Recover GlitchTip-backed host-side ward panic reporting #852

coilyco-ops commented

2026-07-09 18:42:08 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request; review summary: review gate skipped by ~/.ward/config.yaml default

felt: straightforward. The main lift was threading the panic reporter through main without tripping lint, then keeping the redaction hook narrow enough for the existing scrubber.

confidence: high
surprises: go mod tidy refreshed the module graph alongside sentry-go
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request; review summary: review gate skipped by ~/.ward/config.yaml default felt: straightforward. The main lift was threading the panic reporter through `main` without tripping lint, then keeping the redaction hook narrow enough for the existing scrubber. confidence: high surprises: `go mod tidy` refreshed the module graph alongside `sentry-go` follow-ups: none </details>

coilyco-ops closed this issue

2026-07-09 19:02:11 +00:00