334: Error: Unable to retrieve list of comments: Internal Server Error
- UnableToReproduce
- Review Board
| fore*****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| Feb. 16, 2009 |
What's the URL of the page containing the problem? /r/66/diff/ What steps will reproduce the problem? What is the expected output? What do you see instead? This is an intermittent problem that seems to be highly data-dependent. I have a live review request that reliably reproduces this problem. On the "Review" tab (where you must go to publish the review), I get the error message "Error: Unable to retrieve list of comments: Internal Server Error". The review cannot be published. What operating system are you using? What browser? Ubuntu 7.10, Firefox 2.0.0.11 Please provide any additional information below. Just ask if you need more info. I'm Python & Django fluent.
Do you have Firebug installed? Can you attach the output of the failed GET or POST from Firebug's console?
-
+ NeedInfo -
- Priority-Medium + Priority-High + Component-DiffViewer -
+ chipx86
Sorry for the delay; I was on a short break. Data is attached. -Forest
-
+
This looks like another concurrency issue, but I can't for the life of me figure out where it'd be coming from, unless you somehow had two uploads going at once and it created the diffset at the same time. I can add a unique_together variable so that at least one of them will (hopefully) error out if another exists, but it's hard to say if it'll really do anything, and I still don't know what caused the original cause.
-
- NeedInfo + Accepted
-
+ Concurrency
I've had the same issue happen again on a different review. It is not uncommon here. Does reviewboard not deal well when the user has multiple browser windows open? I think that this issue comes up more often from one developer's submissions than with others. Is it possible that different browsing habits of developers has an impact here? I had seen errors in the past that seemed to be related to multiple sessions for the same user, I thought. Don't recall the details...
Regarding concurrency:
Here are the timestamps for the problem DiffSet's:
In [15]: for ds in dss:
....: print ds, ds.timestamp
....:
[244] diff.diff r4 2008-01-10 13:10:42.019849
[245] diff.diff r4 2008-01-10 13:12:10.080810
[246] diff.diff r4 2008-01-10 16:13:35.539740
You can see that #244 and #245 are close, but not so close that they would get the
same revision number. #246 is way off.
There's a race in DiffSet.save:
------------------------------------------------------------------------------------
def save(self):
if self.revision == 0 and self.history != None:
if self.history.diffset_set.count() == 0:
self.revision = 0
else:
self.revision = self.history.diffset_set.latest().revision + 1
super(DiffSet, self).save()
------------------------------------------------------------------------------------
Incrementing the revision number would be more safely done at the database. That
said, I am not thinking this is the cause of the current issue (but it could be the
cause of similar issues...). I know Django doesn't provide a great way to specify a
field value based on a database-calculated value.
It just occured to me: self.history.diffset_set.latest().revision + 1 Perhaps self.history.diffset_set.latest() is being cached?
I guess I meant to say "Perhaps self.history.diffset_set.latest() is returning a cached object?".
-
+ Milestone-Release1.0
-
- Accepted + New -
- chipx86 + -**@gmai***** (Google Code)
A lot has changed since this bug, both in terms of the diff viewer (the symptom in this bug) and our concurrency support. I haven't seen this in a long time, so I'm going to close this. If someone hits it again, please reopen with a new repro case.
-
- New + UnableToReproduce