You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Treat an error's message as an editable label, and search occurrence context #124
A follow-up to #116 and #121, to agree on the design before anything gets built.
With fingerprint set, an error keeps the message it was first reported with, and each occurrence records its own message in its context. That makes the error's message a label rather than a record, and two small dashboard features follow from it.
1. Edit an error's message. Grouping on a request id leaves the error labelled with the first id, for example upstream failed (req_abc123), even though it covers every occurrence. Letting someone edit the label from the error page (upstream failed) fixes that once, and the later emails use the new label. Editing is safe for grouping: the fingerprint is computed from each incoming exception and stored in its own column, never recomputed from the stored message, so new occurrences keep landing on the same error. Editing doesn't merge errors. That's still the fingerprint proc's job.
Rough shape: ErrorsController#update permits message alongside resolved_at, and the error page gets a small inline form. It could keep the original label, for example in a reported_message column, but that's a schema change, so I'd rather leave it out unless you want it.
2. Search, including occurrence context. There's no search on the index today. A search box matching the error's message, plus a text match on occurrence context, would find "which error had req_def456?" and make the per-occurrence messages useful. The context column is JSON or text depending on the adapter. A plain LIKE on its text works on SQLite, Postgres (context::text) and MySQL/MariaDB, and needs no index, at the cost of a scan.
Questions:
Are both of these welcome, one of them, or neither?
For search, is a plain LIKE scan acceptable, or would you want it limited (unresolved errors only, or the last N occurrences)?
For editing, keep the original label somewhere, or treat the label as freely editable?
I'm happy to send the PR or PRs once we've agreed on the shape.
Activity