Open Bug 1399515 Opened 7 years ago Updated 4 years ago

Allow marking OOM based on unprocessed signatures

Categories

(Socorro :: Signature, enhancement, P3)

Product:
Socorro
Component:
Signature
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: jdm, Unassigned)

Details

Reports like https://crash-stats.mozilla.com/report/index/d54a2975-9c55-4567-a92f-c755c0170903 should be counted as an OOM, since we are dealing with a failed allocation by aborting. The original signature looks like core::result::unwrap_failed<hashglobe::FailedAllocationError>, but when the OOM signature check happens I'm pretty sure we only see core::result::unwrap_failed<T> instead, which is too generic to match on appropriately.
Sounds like just an ordering problem? It could be fixed by having the "Check for OOM signature" filter run before the "collapse templates to <T>" filter. (Or at least this is how it is in my simplified understanding of Socorro.)
How urgent is this? Is it "should get fixed this week" or "should get fixed this year"?
It's not a "this week" level of urgent, but if the fix is trivial, I'd say let's just land it and get it out of the way.

(In reply to David Major [:dmajor] from comment #1)
> Sounds like just an ordering problem? It could be fixed by having the "Check
> for OOM signature" filter run before the "collapse templates to <T>" filter.
> (Or at least this is how it is in my simplified understanding of Socorro.)

And of course, it turns out the world is not so simple. `class OOMSignature` is a nicely encapsulated filter, but the template collapsing stuff happens in `normalize_signature` which is baked into an earlier phase. So this change isn't as straightforward as swapping two lines of `DEFAULT_PIPELINE` like I had hoped.

Maybe we can cheat around this? What if we scanned `proto_signature` rather than `signature` here? https://github.com/mozilla-services/socorro/blob/7fb4880387c58874c1ddc07fb2a88b87bb70ced7/socorro/signature/rules.py#L482

If that passes tests, let's go for it. Otherwise, if it's going to be an invasive fix, I'd say sometime in Q4 should be fine.
Ok. I'm going to make this a P2. I'll try to get to it next week--we'll see.
Priority: -- → P2
This is a signature generation issue, so it should be in the "signature" component.
Component: General → Signature

Mark as enhancement.

Type: task → enhancement

We're not going to get to this any time soon, so I'm bumping it down to P3.

Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.