Let apps shape the fingerprint, so a message with a per-request id doesn't split one error into many
Maintainer antworten meist innerhalb von 1 Tag
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 54/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Bereich
- backend, observability
Rechercherichtung
Start by reading Subscriber#report and the fingerprint configuration path; the issue names these as the likely change points but does not give file paths or tests. Compare the proposed configurable fingerprint hook with the narrower message-normalizing option, then check the README and existing subscriber tests. Done means the chosen option groups messages with changing request IDs while retaining the reported message, with configuration documented and tests covering the behavior.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
An error's fingerprint is a hash of its class, message, severity and source. When a message embeds something that changes with every occurrence, such as a request id, a record id or a timestamp, each occurrence becomes an error of its own. The dashboard fills with near-identical errors that each have one occurrence. That hides a real outage, which looks like hundreds of new errors rather than one error with hundreds of occurrences, and since every one is "new", each one is emailed.
The case we hit is API client errors that end with the provider's request id:
Anthropic::Errors::InternalServerError: Internal server error (request_id: req_011CT8...)
What we do today is wrap the subscriber. We unsubscribe SolidErrors::Subscriber and subscribe one that rewrites the exception's message, replacing req_... with a placeholder and moving the id into the context, before handing it on. It works, but it means replacing the gem's subscriber and redefining #message on the exception.
A possible shape: an optional hook that turns the attributes into the fingerprint, defaulting to what happens now:
config.solid_errors.fingerprint = ->(error:, attributes:) {
message = attributes[:message].gsub(/\breq_[A-Za-z0-9]+/, "req_*")
[attributes[:exception_class], message, attributes[:severity], attributes[:source]].join
}
The stored message would stay as reported, so the id is still there to quote, and only the grouping would change. A narrower alternative is a message-normalizing proc that applies only to the fingerprint.
Would something like this be welcome? If so, I can send a small PR: the config option, the call in Subscriber#report, a README section and tests.
- Vorherrschende Sprache
- Ruby
- Sterne
- 498
- Forks
- 36
- Ø Merge
- 12 Std. 38 Min.
- Gemergte PRs (30 T.)
- 20
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
account: profile
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 5 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
bug good first issue help wanted
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
ysb3996-blip/oops#24 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100