None of the four places that resolve an incident writes a resolved_at timestamp, so an incident's lifespan cannot be reconstructed after the fact.
Consequence: there is no way to ask "what was active at 21:40 last Tuesday", which is the time-scrub feature the product promises (glance at your area now, or scrub back through history). updated_at is not a substitute — it moves for reasons unrelated to resolution, and last_thin_at exists specifically so acknowledgements do not touch it.
Blocks build chunk for history scrubbing in UI_REDESIGN.md.
Fix: write resolved_at at every resolution site, including the auto-resolve sweep in summarizer.py (incident_auto_resolve_minutes, currently 90). Backfilling old incidents is optional and lossy — decide whether to approximate from updated_at for existing rows or leave them null and treat null as unknown.
None of the four places that resolve an incident writes a `resolved_at` timestamp, so an incident's lifespan cannot be reconstructed after the fact.
Consequence: there is no way to ask "what was active at 21:40 last Tuesday", which is the time-scrub feature the product promises (glance at your area now, or scrub back through history). `updated_at` is not a substitute — it moves for reasons unrelated to resolution, and `last_thin_at` exists specifically so acknowledgements do not touch it.
Blocks build chunk for history scrubbing in `UI_REDESIGN.md`.
Fix: write `resolved_at` at every resolution site, including the auto-resolve sweep in `summarizer.py` (`incident_auto_resolve_minutes`, currently 90). Backfilling old incidents is optional and lossy — decide whether to approximate from `updated_at` for existing rows or leave them null and treat null as unknown.
Fixed in commit 70d63abeaa on Server main. resolved_at is now written alongside status=resolved at every site that resolves an incident: the signal-based auto-resolve and the master-resolve propagation in incident_correlator.py, the 90-minute stale sweep in summarizer.py, both scene-resolution loops in upload.py, and the reprocess/correction path in calls.py (the first two of those werent explicitly named in the issues four sites but had the same gap). No backfill: existing resolved incidents keep resolved_at = null, meaning resolved before this field existed rather than never resolved, per the issues own guidance that backfilling is optional and lossy. New tests in tests/test_correlator_gate.py cover both the signal-resolve and master-resolve paths.
Fixed in commit 70d63abeaaa24a56aa6fd3cbc6320e50e9f77b98 on Server main. resolved_at is now written alongside status=resolved at every site that resolves an incident: the signal-based auto-resolve and the master-resolve propagation in incident_correlator.py, the 90-minute stale sweep in summarizer.py, both scene-resolution loops in upload.py, and the reprocess/correction path in calls.py (the first two of those werent explicitly named in the issues four sites but had the same gap). No backfill: existing resolved incidents keep resolved_at = null, meaning resolved before this field existed rather than never resolved, per the issues own guidance that backfilling is optional and lossy. New tests in tests/test_correlator_gate.py cover both the signal-resolve and master-resolve paths.
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.
None of the four places that resolve an incident writes a
resolved_attimestamp, so an incident's lifespan cannot be reconstructed after the fact.Consequence: there is no way to ask "what was active at 21:40 last Tuesday", which is the time-scrub feature the product promises (glance at your area now, or scrub back through history).
updated_atis not a substitute — it moves for reasons unrelated to resolution, andlast_thin_atexists specifically so acknowledgements do not touch it.Blocks build chunk for history scrubbing in
UI_REDESIGN.md.Fix: write
resolved_atat every resolution site, including the auto-resolve sweep insummarizer.py(incident_auto_resolve_minutes, currently 90). Backfilling old incidents is optional and lossy — decide whether to approximate fromupdated_atfor existing rows or leave them null and treat null as unknown.Fixed in commit
70d63abeaaon Server main. resolved_at is now written alongside status=resolved at every site that resolves an incident: the signal-based auto-resolve and the master-resolve propagation in incident_correlator.py, the 90-minute stale sweep in summarizer.py, both scene-resolution loops in upload.py, and the reprocess/correction path in calls.py (the first two of those werent explicitly named in the issues four sites but had the same gap). No backfill: existing resolved incidents keep resolved_at = null, meaning resolved before this field existed rather than never resolved, per the issues own guidance that backfilling is optional and lossy. New tests in tests/test_correlator_gate.py cover both the signal-resolve and master-resolve paths.