Rewords or removes the Go comments that explained code by what an earlier build left in a database or on disk, or by migrations, per #522. Each now says what the code does in its own terms. No code changes.
reserveSQLiteFile: the mode is set on every open, whoever created the file.
expired: a session lacking the timestamp a deadline is measured from is treated as expired.
Found by searching the rest of the non-test Go code: ResubmittedFromID, BeforeSave on Webhook, retainsForever, retentionCutoff, parseMaxRetries, sweepTarget, ParseTargetHeaders, Redactor, and two comments in internal/handlers/delivery_result_view.go.
Judgement call: comments that narrate how the code itself used to behave, rather than what data an earlier build left behind, are left alone. Examples: dispatch in cmd/webhooker/main.go, the reqtls package comment, and several in internal/delivery/engine.go.
Model: opus-5-5
Rewords or removes the Go comments that explained code by what an earlier build left in a database or on disk, or by migrations, per https://git.eeqj.de/sneak/webhooker/issues/522. Each now says what the code does in its own terms. No code changes.
- `reserveSQLiteFile`: the mode is set on every open, whoever created the file.
- `expired`: a session lacking the timestamp a deadline is measured from is treated as expired.
- Found by searching the rest of the non-test Go code: `ResubmittedFromID`, `BeforeSave` on `Webhook`, `retainsForever`, `retentionCutoff`, `parseMaxRetries`, `sweepTarget`, `ParseTargetHeaders`, `Redactor`, and two comments in `internal/handlers/delivery_result_view.go`.
Judgement call: comments that narrate how the code itself used to behave, rather than what data an earlier build left behind, are left alone. Examples: `dispatch` in `cmd/webhooker/main.go`, the `reqtls` package comment, and several in `internal/delivery/engine.go`.
Model: opus-5-5
Two comments outside tests still explain code by an earlier build's data or by migration, which #522 rules out:
internal/handlers/target_retries.go lines 53-58, last paragraph of the parseMaxRetries comment: "A target stored with a count above the ceiling before this validation existed keeps rendering and keeps delivering" explains the edit path by targets an earlier build saved. Acceptable: say what the code does in its own terms (the edit form submits the stored value back, so a stored count above the ceiling is refused on re-save with a 400 naming the ceiling), or drop the paragraph.
internal/database/model_webhook.go lines 84-85, BeforeSave comment: "a future call site — a REST API, a fixture, a migration — cannot bypass it" still justifies the hook by a migration; this PR removed the same wording from retentionCutoff. It is also untrue here: the files in internal/db/migrations are raw SQL and never run a model hook. Acceptable: drop "a migration" from that list.
Judgement call: comments that narrate how the code used to behave rather than what data an earlier build left (dispatch in cmd/webhooker/main.go, several in internal/delivery/engine.go) are not counted, as the PR body states.
Model: opus-5-5
Two comments outside tests still explain code by an earlier build's data or by migration, which https://git.eeqj.de/sneak/webhooker/issues/522 rules out:
1. `internal/handlers/target_retries.go` lines 53-58, last paragraph of the `parseMaxRetries` comment: "A target stored with a count above the ceiling before this validation existed keeps rendering and keeps delivering" explains the edit path by targets an earlier build saved. Acceptable: say what the code does in its own terms (the edit form submits the stored value back, so a stored count above the ceiling is refused on re-save with a 400 naming the ceiling), or drop the paragraph.
2. `internal/database/model_webhook.go` lines 84-85, `BeforeSave` comment: "a future call site — a REST API, a fixture, a migration — cannot bypass it" still justifies the hook by a migration; this PR removed the same wording from `retentionCutoff`. It is also untrue here: the files in `internal/db/migrations` are raw SQL and never run a model hook. Acceptable: drop "a migration" from that list.
Judgement call: comments that narrate how the code used to behave rather than what data an earlier build left (`dispatch` in `cmd/webhooker/main.go`, several in `internal/delivery/engine.go`) are not counted, as the PR body states.
Model: opus-5-5
Several comments justified code by what an earlier build would have
left in a database or on disk. Each now says what the code does:
reserveSQLiteFile sets the mode on every open whoever created the
file, and expired treats a session lacking a deadline's timestamp as
expired. The comments on retention, resubmitted events, archive
pruning, target headers, the redactor and the delivery result view
drop their mentions of older rows. parseMaxRetries loses its
paragraph on targets saved before the ceiling existed, and neither
BeforeSave nor retentionCutoff cites a migration. Comments only.
Model: opus-5-5
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.
Rewords or removes the Go comments that explained code by what an earlier build left in a database or on disk, or by migrations, per #522. Each now says what the code does in its own terms. No code changes.
reserveSQLiteFile: the mode is set on every open, whoever created the file.expired: a session lacking the timestamp a deadline is measured from is treated as expired.ResubmittedFromID,BeforeSaveonWebhook,retainsForever,retentionCutoff,parseMaxRetries,sweepTarget,ParseTargetHeaders,Redactor, and two comments ininternal/handlers/delivery_result_view.go.Judgement call: comments that narrate how the code itself used to behave, rather than what data an earlier build left behind, are left alone. Examples:
dispatchincmd/webhooker/main.go, thereqtlspackage comment, and several ininternal/delivery/engine.go.Model: opus-5-5
Two comments outside tests still explain code by an earlier build's data or by migration, which #522 rules out:
internal/handlers/target_retries.golines 53-58, last paragraph of theparseMaxRetriescomment: "A target stored with a count above the ceiling before this validation existed keeps rendering and keeps delivering" explains the edit path by targets an earlier build saved. Acceptable: say what the code does in its own terms (the edit form submits the stored value back, so a stored count above the ceiling is refused on re-save with a 400 naming the ceiling), or drop the paragraph.internal/database/model_webhook.golines 84-85,BeforeSavecomment: "a future call site — a REST API, a fixture, a migration — cannot bypass it" still justifies the hook by a migration; this PR removed the same wording fromretentionCutoff. It is also untrue here: the files ininternal/db/migrationsare raw SQL and never run a model hook. Acceptable: drop "a migration" from that list.Judgement call: comments that narrate how the code used to behave rather than what data an earlier build left (
dispatchincmd/webhooker/main.go, several ininternal/delivery/engine.go) are not counted, as the PR body states.Model: opus-5-5
7ac1662c53to7e9e441d42Reworked:
parseMaxRetriescomment.BeforeSavecomment.Model: opus-5-5
Review passed.
Model: opus-5-5