Closed Bug 1033258 Opened 10 years ago Closed 10 years ago

bzexport fails to leave a comment when attaching a file using the BzAPI compatibility layer

Categories

(bugzilla.mozilla.org :: Extensions, defect)

Production
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: Gijs, Assigned: dkl)

References

Details

I ran ./mach mercurial-setup yesterday, which updated my version-control-tools. The two times I've used bzexport since, my --comment "Here's a comment" have been sent to /dev/null (ie not appeared on the bug, with no warning) and the second time, bzexport failed to assign me the bug. Full input/output:


gkruitbosch-16516:fx-team gkruitbosch$ hg bzexport --review ":jaws" --comment "So this was fun... To get stuff to wrap, I needed to switch to non-XUL display style (block or flex). For the reset button to be end-aligned, I needed a flexible space (using just float: right/left looked weird once stuff started wrapping). For the flexible space to work I needed to use display: flex and flex-wrap: wrap. When wrapping, that wasn't increasing the height of the footer, which I fixed by making the entire thing be display: flex... Everything seems to work, but yeah, hence the extensive changes. The margins don't collapse (presumably because of XUL frames?) and so they are carefully selected in order to maintain the current style (15px total spacing between button edge and footer edge, 10px spacing between each button, both horizontally and vertically)." --ffprofile default
Requesting review from jaws@mozilla.com
987586-flex-wrap-customization-mode uploaded as https://bugzilla.mozilla.org/attachment.cgi?id=8449280&action=edit
Error: Mid-air collision
abort: Error when updating bug 987586: {u'status': 'ASSIGNED', u'last_change_time': u'2014-07-02T08:07:02Z', u'assigned_to': {'name': u'gijskruitbosch+bugs@gmail.com'}, u'update_token': u'1404293747-<snipped-for-privacy>', u'ref': u'https://bugzilla.mozilla.org/bzapi/bug/987586', u'id': 987586}


Ed noticed that https://hg.mozilla.org/hgcustom/version-control-tools/rev/782f314c73d4 landed recently. I don't know if these are issues in the bzapi compat layer or in bzexport, but it sure is annoying :-)
Do you know when you last updated?
(In reply to Ed Morley [:edmorley UTC+0] from comment #1)
> Do you know when you last updated?

Before yesterday? No. :-(
Probably a long time. I know that feedback flags already worked, though... so "long" might be relative.
Feedback was implemented ~7-8months ago in bug 728778 (and followups), a half dozen other bugs have landed since:
https://hg.mozilla.org/hgcustom/version-control-tools/log/tip/hgext/bzexport/__init__.py

Though I've not seen the issues before (and I don;t have ted's endpoint change), so I'm most suspicious about that.
It looks like using multiple reviewers is also broken. :-(

Error: There is no user named 'neil@httl.net, mconley@mozilla.com'. Either you mis-typed the name or that user has not yet registered for a Bugzilla account.
I've verified that at least the comment eating goes away if I update to the revision directly before the API change.
Depends on: 1033394
Should be fixed by backout:
https://hg.mozilla.org/hgcustom/version-control-tools/rev/30b6d858ed1c

The diagnosis and relanding will occur in bug 1033394.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
given bug 1033394 is tracking switching bzexport to the new endpoint, to avoid confusion i'm going to reopen this bug and move it to the bmo component so we can investigate what's going on.
Assignee: nobody → dkl
Blocks: 1033394
Status: RESOLVED → REOPENED
Component: bzexport → Extensions: BzAPI Compatibility
No longer depends on: 1033394
Product: Other Applications → bugzilla.mozilla.org
Resolution: FIXED → ---
Version: unspecified → Production
Depends on: 880669
Summary: bzexport is eating my comments and failing to assign me bugs → bzexport fails to leave comments/assign bugs when using the BzAPI compatibility layer
(sigh, sorry spam)
Blocks: 880669
No longer depends on: 880669
I have found the issue with comments not getting applied when adding a new attachment and can check in the fix for that anytime. 

The mid air issue when updating the bug's status and assignee is different issue and I feel it is because we use the MySQL slaves for GET /bug/<id> calls and that the previously created attachment updates the last_changed_timestamp of the bug. But the timestamp had not yet replicated to the slaves yet. So it thinks it is a mid-air.

Glob, what if we were to change Bugzilla::WebService::Bug::get to only switch to shadow db if the user is not logged in, otherwise return master. We do similar to this already with show_bug.cgi?

dkl
Flags: needinfo?(glob)
(In reply to David Lawrence [:dkl] from comment #9)
> Glob, what if we were to change Bugzilla::WebService::Bug::get to only
> switch to shadow db if the user is not logged in, otherwise return master.
> We do similar to this already with show_bug.cgi?

sounds reasonable.  can you spin that out into a different upstream bug please.
No longer blocks: 880669
Depends on: 880669
Flags: needinfo?(glob)
(In reply to Byron Jones ‹:glob› from comment #10)
> (In reply to David Lawrence [:dkl] from comment #9)
> > Glob, what if we were to change Bugzilla::WebService::Bug::get to only
> > switch to shadow db if the user is not logged in, otherwise return master.
> > We do similar to this already with show_bug.cgi?
> 
> sounds reasonable.  can you spin that out into a different upstream bug
> please.

Bug 1033445

Here is the commit to fix the attachment comments issue:
To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   48577f2..e0d898d  master -> master

dkl
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Summary: bzexport fails to leave comments/assign bugs when using the BzAPI compatibility layer → bzexport fails to leave a comment when attaching a file using the BzAPI compatibility layer
Thank you for fixing that :-)
Depends on: 508541
Component: Extensions: BzAPI Compatibility → Extensions
You need to log in before you can comment on or make changes to this bug.