426: problems publishing review replies
- ThirdParty
- Review Board
| mbe****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
| May 16, 2008 |
What steps will reproduce the problem? 1. Post a review request 2. Publish a review of the request 3. Add comments on the review itself (not the diffs page) 4. Hit Publish on the green "This reply is a draft. Be sure to publish when finished." box. This fairly consistently pops up the error message: "Error: Saving the reply draft has failed due to a server error.. Please try again later. If this continues to happen, please report it to your administrator" What operating system are you using? What browser? I'm running r1209 of reviewboard, r7197 trunk django. I am running the django development server. The server codes look fine. Here's the relevant chunk of the server log: [06/Mar/2008 12:36:10] "POST /api/json/reviewrequests/11/reviews/12/replies/draft/ HTTP/1.1" 200 336 [06/Mar/2008 12:36:24] "POST /api/json/reviewrequests/11/reviews/12/replies/draft/save/ HTTP/1.1" 200 14 The error message shows up with the replies/draft/save POST. The funny thing is, the error message is wrong. If I reload the page, the comment is published just fine. I dug around in the code a bit to try to figure out what was going on. When I added some print statements to review_reply_draft_save in webapi/json.py I found that the failure was not caused by a Review.DoesNotExist exception. (However, once the first failure occurs, additional attempts to 'Publish' or 'Discard' do trigger the Review.DoesNotExist exception. This is just a variation on issue #417.) Big clue: When I add a print of the request object, the problem consistently goes away! Even when I add a print of the request.POST attribute the problem goes away. I don't know enough about django to know what this means, though.
The print of the request object is in the review_reply_draft_save() function; sorry this wasn't clear. BTW, when I saw that printing request fixed the problem, I assumed there was just some kind of race condition. However, adding time.sleep() delays didn't fix the problem.
Are you running Firefox, and do you have Firebug installed? If so, when you reproduce this, look at the associated request in the Firebug console and paste the results of the request.
-
+ Component-Reviews
Ok, I installed Firebug and while I couldn't repeat this at home (Firefox 2.0.? on
OSX) it is still repeatable at work (Firefox 1.5.0.8 on Linux). So, browser
dependency fun?
Firebug shows two posts in rapid succession on hitting the Publish button; the first
is to
http://devserver:8000/api/json/reviewrequests/15/reviews/37/replies/draft/
with the post value
value=a%20third%20comment%20from%20work&id=37&type=body_top&review_id=37
and the response
{"reply": {"body_top": "a third comment from work", "ship_it": false, "timestamp":
"2008-03-24 05:43:14", "comments": [], "id": 43, "user": {"username": "beachy",
"first_name": "Mike", "last_name": "Beachy", "url": "\/users\/beachy\/", "email":
"beachy@workaddress.com", "fullname": "Mike Beachy", "id": 1}, "body_bottom": "",
"public": false}, "stat": "ok"}
The second post is to /api/json/reviewrequests/15/reviews/37/replies/draft/save/
with a post of
dummy
and the response of
Loading...
This is a very annoying bug any progress?
I'm still not sure what's going on. Is there really no response from the server? "Loading..." is pretty weird.
Hey posix4e, do you see the same firebug info for this case that I do?
POST
http://##############:8070/api/json/reviewrequests/21/reviews/41/replies/draft/save/
(220ms)utilities.js (line 170)
ParamsHeadersPostResponse
Response Headers
Request Headers
Loading...
POST
http://###############:8070/api/json/reviewrequests/21/reviews/41/replies/draft/save/
(170ms)utilities.js (line 170)
ParamsHeadersPostResponse
Response Headers
Request Headers
{"stat": "fail", "err": {"msg": "Object does not exist", "code": 100}}
POST
http://############:8070/api/json/reviewrequests/21/reviews/41/replies/draft/save/
(181ms)utilities.js (line 170)
ParamsHeadersPostResponse
Response Headers
Request Headers
{"stat": "fail", "err": {"msg": "Object does not exist", "code": 100}}
Could this possibly be a weird nfs cacheing bug?
This only happens with the test server, it went away in production.