Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Let apps shape the fingerprint, so a message with a per-request id doesn't split one error into many

Ouverte
  • Quelque chose ne va pas ?
#116 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@namolnad y travaille déjà.

Depuis le 19/10/2026.

  • #121 par @namolnad — ouverte

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
54/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rails, ruby
Domaine
backend, observability

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Ruby
Étoiles
498
Forks
36
Merge moyen
12 h 38 min
PR mergées (30 j)
20

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Issues similaires

Plus d'issues Ruby

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.