Today I wanted to report a crash in Nautilus using ABRT. However, I received this error during ABRT reporting:
--- Running report_Bugzilla --- Checking for duplicates Creating a new bug... Adding External URL to bug 2353858 Adding attachments to bug 2353858 Failed to attach 'environ' to bug # 2353858. Server says: 409 Conflict {"error":true,"documentation":"https://bugzilla.redhat.com/docs/en/html/api/index.html","code":31113,"message":"Red Hat Bugzilla's database reported a query serialization error. Most likely this occurred because another user or process attempted to change the same data that you were attempting to change. Please press Back and retry the transaction. <pre> UPDATE bugs SET delta_ts = ? WHERE bug_id = ? at /var/www/html/bugzilla/Bugzilla/Bug.pm line 1523. </pre>"} Traceback (most recent call last): File "/usr/bin/reporter-bugzilla", line 833, in <module> attachment, attachments_bug_id, response.json()['ids'][0]) ^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'json' ('report_Bugzilla' exited with 1)
The important part is:
Red Hat Bugzilla's database reported a query serialization error. Most likely this occurred because another user or process attempted to change the same data that you were attempting to change.
The bug was only partially reported, with the most important attachments missing: https://bugzilla.redhat.com/show_bug.cgi?id=2353858
I believe the problem is in comment 4, which is a "report upstream" script that Workstation runs for most/selected GNOME components.
The immediate response of the script, before the bug was fully reported, caused a request conflict in Bugzilla, and prevented ABRT from fully reporting it.
I see this as a problem, because important attachments (e.g. a full stacktrace) are missing. That severely limits the usefulness, if the user wanted to report the crash upstream.
The easiest solution is probably not to trigger the script immediately, but delayed (a minute or two should be enough). Or make it run in batches (e.g. every 30 minutes, every hour) on all bugs detected during that interval. This would not eliminate, but minimize the likelihood of such issues.
@blc do you know it it's possible to add some timeout as Kamil is suggesting? This is about the following Bugzilla rule - https://bugzilla.redhat.com/page.cgi?id=ruleengine%2Fdetails%2Findex.html&rule_name=Further%20Upstream%20First%3A%20GNOME
I think Kamil is right and this is a multi-update situation.
There is no "sleep" feature in BRE, but I could change the rule to run once per day instead of at time of bug update. I'm loathe to do this though because it would mean that whoever files a bug will get the feedback they filed in the wrong place as late as 24 hours after, long since they thought they'd done their part.
Currently this rule runs first in BRE. I could have it run later.... but there are only 3 rules total so I don't think it would slow down a lot.
Probably the best solution would be to split the rule in 2, allowing a different behavior depending on some characteristic of the initial bug report. As a bad example, I could have the current rule only trigger when anybody but Kamil files the issue, and a second rule that causes the rule to run once a day when it's Kamil who files the issue. This isn't actually a good solution, but it's basically the kind of capability that BRE has.
A more realistic rule would be to check something like the "QA Whiteboard" for something like "PauseBRE", then the tool that this issue is being filed with would set "QA Whiteboard" to "PauseBRE" on creation, attach any files, add any comments, then clear the "PauseBRE" value from "QA Whiteboard". All the rules that might cause a problem would then look for this value and not trigger on update if the value is there. Or we could use a flag. In this circumstance I would add a rule that runs every day that automatically clear the "PauseBRE" value. Or a flag. You get the idea. Let me know if there is or easily could be some value in the initial BZ that we could use to pause the rules engine and I can take it from there.
All ABRT-reported bugs have [abrt] in the Summary (title). They also have abrt_hash: in the Whiteboard. Can we use one of these to move the rule to the "update once per day" bucket?
[abrt]
abrt_hash:
For manual bug submission, I think the immediate response is not a big problem, the reporter can deal with it even if a conflict is encountered (Bugzilla offers you several options to continue). We just need to handle automatic reports better, which means ABRT (and I'm not aware of anything else). So detecting ABRT keywords could be a good enough solution.
This sounds like an excellent short-term solution.
A more realistic rule would be to check something like the "QA Whiteboard" for something like "PauseBRE", then the tool that this issue is being filed with would set "QA Whiteboard" to "PauseBRE" on creation, attach any files, add any comments, then clear the "PauseBRE" value from "QA Whiteboard".
And this sounds like an excellent long-term solution. This would need an ABRT bug report.
Log in to comment on this ticket.