feat(issue-platform): Support passing fingerprints with multiple hashes when sending occurrences #87311
Conversation
…es when sending occurrences This introduces handling for fingerprints with multiple components to the issue platform. This works in the same way that events do - we try to fetch grouphashes for each component, where earlier hashes have priority. If none exist, create a new group and associated both hashes with that group. If there are multiple groups associated with the hashes, then associate this occurrence to the first group found, and don't change the hash association. This shouldn't happen in the issue platform in general, but worth being cautious. I will follow up with another pr to handle this for status changes as well.
github-actions
bot
added
the
Scope: Backend
There was a problem hiding this comment.
Maybe (probably) this ship has sailed long since, but as somebody quite familiar with our regular grouping process, I'm finding this code a little confusing because of the fact that the field called fingerprint includes hashes rather than the fingerprint. Any chance of aligning the naming?
(Even if we can't change the schema field name, could we change the variable names in the code here, so we're referring to things as just "hashes" rather than "fingerprint" or "fingerprint_hashes?" I'll grant it's not a huge deal, but they do mean distinctly different things on the error-grouping side.)
Otherwise this change looks good.
Isn't that how the error fingerprints work too? We have a fingerprint, which is an array of strings, where each string in the array might map to a hash value in |
…es when sending status updates This is a follow up to #87311 We now allow status updates with multiple hashes to be sent to the issue platform. We have a shared function here with statistical detectors, which I've also updated to pass work with full fingerprints. There should be no change to how the detector works.
…es when sending status updates This is a follow up to #87311 We now allow status updates with multiple hashes to be sent to the issue platform. We have a shared function here with statistical detectors, which I've also updated to pass work with full fingerprints. There should be no change to how the detector works.
…es when sending status updates This is a follow up to #87311 We now allow status updates with multiple hashes to be sent to the issue platform. We have a shared function here with statistical detectors, which I've also updated to pass work with full fingerprints. There should be no change to how the detector works.
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
This introduces handling for fingerprints with multiple components to the issue platform. This works in the same way that events do - we try to fetch grouphashes for each component, where earlier hashes have priority. If none exist, create a new group and associated both hashes with that group.
If there are multiple groups associated with the hashes, then associate this occurrence to the first group found, and don't change the hash association. This shouldn't happen in the issue platform in general, but worth being cautious.
I will follow up with another pr to handle this for status changes as well.