Closed Bug 1234162 Opened 9 years ago Closed 8 years ago

Mozreview broken after pushing commits with empty file

Categories

(MozReview Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pehrsons, Unassigned)

References

()

Details

I'm using git as my daily version control system, but mozreview for reviews.

This creates some problems, especially when reordering or adding/removing commits in an already-pushed-to-mozreview patch set.

Typically I'd have rebased in git-land and would export all the commits to patches, then reset mercurial to latest m-c and import all the patches. Mozreview will in this case map the commits to the previous push depending on order, so if a new commit is inserted in the middle, all commits coming after it will be mapped wrong.

To remedy this, I inserted dummy commits (1. add an empty file, 2. remove the same empty file, etc.) with hg in the same places as I had put new ones with git, to get the order right thanks to hg evolve. I then wanted to push a second wave updated to my git patch set. Pushing the dummy commits, however, rendered mozreview broken.

https://reviewboard.mozilla.org/r/22565/ now shows up empty, and bug 1208371 says "Error loading review requests: INTERNAL SERVER ERROR".

I'm holding off pushing the fully updated patch set until you have had a chance to look into this issue.
Do you want to investigate this further?

You may do it now, but I soon want to push patches to that bug again, which will certainly change the state of the bug in mozreview.
Flags: needinfo?(mdoglio)
I actually gave up on this when I read your bug description which mentions that you are using git. Git support for mozreview is not there yet and :gps is working on it in bug 1153053. He may also have some ideas on how to unlock your review request, I'll NI him.
Flags: needinfo?(mdoglio) → needinfo?(gps)
mercurial, not git, is being used to push to mozreview here.
The fact that git was used to construct patches before importing them into mercurial is irrelevant.
I'm in need of pushing stuff to this mozreview again. Do you want to investigate what's broken or could you perhaps reset it so I don't run into more issues?

What karlt notes is true. I only modified the original push with hg to cater for a future push based on patches imported from git (which hasn't happened yet).
Flags: needinfo?(mdoglio)
:pehrsons I'm not sure I know how to fix/unlock that review request. :smacleod may have some ideas about that.
Flags: needinfo?(mdoglio) → needinfo?(smacleod)
These review requests are in a very strange state, we have a serious bug somewhere (unless you were manually making API requests to Review Board, which I doubt).

It would really help me diagnose the problem and how we reached it if you could give me a breakdown of what you did including when you made the commits, when you pushed them, but also when you performed actions on Review Board (Most importantly publishing).
Flags: needinfo?(smacleod) → needinfo?(pehrsons)
(In reply to Steven MacLeod [:smacleod] from comment #7)
> These review requests are in a very strange state, we have a serious bug
> somewhere (unless you were manually making API requests to Review Board,
> which I doubt).
I certainly wasn't.


> It would really help me diagnose the problem and how we reached it if you
> could give me a breakdown of what you did including when you made the
> commits, when you pushed them, but also when you performed actions on Review
> Board (Most importantly publishing).

For the time, this is the relevant IRC log from #mozreview on December 21st 2015 (local time is Taipei):
> [17:31:39] <pehrsons> So I think I broke mozreview, if anyone wants to take a look: https://reviewboard.mozilla.org/r/22565/
> [17:33:31] <pehrsons> Should have been some 40 patches in there, looked fine until I published via the web ui
> [17:36:25] <pehrsons> Oh, bugzilla now reports an error as well: https://bugzilla.mozilla.org/show_bug.cgi?id=1208371, "Error loading review requests: INTERNAL SERVER ERROR"
> [17:36:33] <firebot> Bug 1208371 — NEW, pehrsons@gmail.com — Implement MediaStream/MediaStreamTrack.clone()

I just updated my hg repo to the revision mozreview reported as published at the time, inserted a couple of dummy commits in the middle (add empty file, remove same empty file, etc.), pushed, removed all reviewers in the web ui, published (I reckon time between push and publish was a couple of minutes), waited for a good long while (40 patches took a while, and now I have 80 for the next push), they showed up on the bug [1], mozreview was broken.

[1] The comments made by mozreview on the bug are bug 1208371 comment 220 - timestamped "2015-12-21 17:17:37 CST ", until bug 1208371 comment 258 - timestamped "2015-12-21 17:19:15 CST"; there are some obsoletions made after that so the final timestamp is "2015-12-21 17:19:27 CST". That's 1m50s after the first entry. Sounds too simple but... timeout issue at 2 minutes? :-)
Flags: needinfo?(pehrsons) → needinfo?(smacleod)
Thanks for all the information. Another review series fell into a similar state recently, so it's pretty obvious we have a subtle but serious bug here. I should have enough information now that you can update your review request without worrying about destroying anything.

I think our best bet for solving this is finishing up the work in Bug 1229468 and then investigating from there.
Flags: needinfo?(smacleod)
Thanks. Let's see how it goes.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(gps)
Resolution: --- → WONTFIX
Product: Developer Services → MozReview
You need to log in before you can comment on or make changes to this bug.