392: automatically save fields in the "edit state" when publishing
- Fixed
- Review Board
| andy****@gmai***** (Google Code) (Is this you? Claim this profile.) | |
 |
|
| Dec. 27, 2008 |
What's the URL of the page containing the problem? r/<review#> What steps will reproduce the problem? 1. edit something on an existing review or create a new review 2. click publish without hitting enter for each edit field What is the expected output? What do you see instead? i would expect even the fields that were left in the "edit state" to be saved as well. instead, they are not. What operating system are you using? What browser? xp, ff2 Please provide any additional information below. a lot of people have been confused by this on our local review board.
This is how it works today. I've taken advantage of that quite a bit. How recent is the Review Board server?
Last Changed Author: trowbrds Last Changed Rev: 1102 Last Changed Date: 2008-01-06 01:53:25 -0800 (Sun, 06 Jan 2008) i've heard complaints specifically about the "summary" field not being saved when publishing a new review without stroking enter. not certain about the other ones.
i just created a review and hit this problem. here's what i did: 1) submit a review using post-review 2) visit the page to create a new review on xp using ff 2.0.0.11 3) enter each field without stroking enter or hitting "ok" 4) publish the review observed: summary is saved branch is not saved bugs is not saved groups is saved people is saved description is not saved testing is saved
i updated the review i created in comment 3 by editing each unsaved field and hitting "ok" in the description field to trigger the "publish" prompt. everything saved as expected in this case.
I think this is a read-modify-write race on the draft object. Each field is sent to the server in parallel requests. The problem comes when two or more threads read the existing state of the draft at the same time, then make a single change and save. The last one to save will overwrite the changes from the other. Either draft modifications need to be made atomic, or else saving multiple fields needs to be serialized or batched.
I believe we fixed this some time again/. Please reopen if you're still hitting this.
-
+ Fixed
Sorry, no, this still seems to be an issue. Please reopen this bug. I can almost always reproduce this if I fill in every field, leave them unsaved, and then hit publish. Most of them are OK, but usually one or two of the fields will be lost. Reproducibility may depend on the server mode you're testing with too. I never see a problem under devserver.sh, but I do see it when running server.sh. There seem to be different levels of concurrency in play between the two modes.
-
- Fixed + Accepted -
+ Component-Reviews + Milestone-Release1.0 + Usability
-
- Accepted + New
-
- New + Confirmed
This is fixed in the UI rewrite. I'll close this once it's committed.
-
- Confirmed + Started -
+ chipx86