3660: Files randomly get lost from a review request ("This is an empty file.")

to***@salsita******** (Google Code) (Is this you? Claim this profile.)
Jan. 12, 2015
3601 
What version are you running?
2.0.8

What's the URL of the page containing the problem?
https://review.salsitasoft.com/r/9638/diff/#

What steps will reproduce the problem?
1. Post a review request via RBTools (0.6.2) Publish.
2. Go to the review request and add a few comments. Publish.
3. Return to the review request later on. 


What is the expected output? What do you see instead?
I see "This is an empty file." for some of the files included in the review request. Although they are definitely not empty and they used to be there (I can see the comments I added to the lines in those files on the main review request page).

IOW - I'm losing files in the review requests! Which sucks bad.

What operating system are you using? What browser?
Mac OS 10.9.2, Chrome 38


Please provide any additional information below.
#1 to***@salsita******** (Google Code) (Is this you? Claim this profile.) 
So, I looked into the DB and it seems the issue is that "Diff set history" id for that review request is wrong - it points to a diffsethistory item that belongs to another repository.

Furthermore, the id it points to is quite recent; much more recent than what it should point to - assuming the ids are incremental. So it seems as if it was overwritten by a new review request.
david
#2 david 
What version control system are you using?
  • +NeedInfo
#3 to***@salsita******** (Google Code) (Is this you? Claim this profile.) 
We're using Git.
#4 to***@salsita******** (Google Code) (Is this you? Claim this profile.) 
BTW scratch that Diff set history, that's probably misleading, I couldn't find it with any other affected review requests.

But this is quite a blocker - files in cca 10% of our review requests are just getting lost rendering the reviews useless.
#5 to***@salsita******** (Google Code) (Is this you? Claim this profile.) 
We'e upgraded to 2.0.11 since then and it's still the same.
#6 mat****@salsita******** (Google Code) (Is this you? Claim this profile.) 
Note that https://code.google.com/p/reviewboard/issues/detail?id=3601 appears to be the same issue.
#7 mat****@salsita******** (Google Code) (Is this you? Claim this profile.) 
This is labeled `NeedsInfo`. What info specifically do you need? This is a critical issue for us that is severely disrupting our workflow. Would anyone have time to take a look at our database and see if that reveals any information about why files are disappearing from our review requests?

To reiterate, we post a review request and all files are there. We generally comment on the files to annotate them immediately after publishing. However, when the reviewer goes to do the review, some files are gone and labeled "This is an empty file".
chipx86
#8 chipx86 
Hi Tomas, Matthew,

At any point did you guys transition the database from one server to another, or one type of database to another? That or hand-editing is the only way I can think of to describe why a DiffSetHistory ID has changed.

Can you show me your Git repository configuration on Review Board?

Also, are these newly-introduced files that are having this problem, or changes made to existing files?
#9 mat****@salsita******** (Google Code) (Is this you? Claim this profile.) 
I guess the DiffSetHistory thing was a red herring according to Tomas.

I'm attaching a screenshot of the relevant snippet of the repo config. It all looks very standard to me. The really weird thing is that the diffs for the files in question are definitely there when the review is published. They somehow "disappear" afterwards so if the reviewer goes to check out the review later it just says "This is an empty file".
chipx86
#10 chipx86 
It's deeply alarming that they'd "disappear" like that. Review Board is extremely heavily tested with GitHub (we use it every day ourselves, and monitor a large install with many GitHub users), and haven't come across this at all yet. Hmmmmm...

We only show "This is an empty file" if it's a newly-created file of 0 bytes. The "new file" state is computed at diff upload time and never modified, and the number of changes happens when we parse the uploaded file content and generate a diff view for it.

So I'm seriously leaning toward corruption somewhere.

What type of database are you using?

Are you using any sort of multi-server approach for your web server or database servers?

Any sort of special work you're doing against the database? Anything with how you do backups?
chipx86
#11 chipx86 
Also, can you shed some light on the DiffSetHistory thing?  It may not be a red herring. It may be one more symptom.
#12 mat****@salsita******** (Google Code) (Is this you? Claim this profile.) 
The one thing that occurs to me is that the repo config in question in pretty old (from a previous RB version). We ended up creating a new repo in Github with the same name and reusing this repo config. I've asked our sysadmin to set up a completely new repo in RB so let's see if that magically fixes the problem.
#13 to***@salsita******** (Google Code) (Is this you? Claim this profile.) 
Re: The diff history thing - I don't have any more info on that other than what I already wrote. I can't find the relevant diffsethistory item in the DB unfortunately and when I check the other reviews with the missing files, their diffsethistories are fine.

Which leads me to believe either I got confused when I was crawling the DB back then to see any potential inconsistencies or that the diffsethistories were broken but that did now affect the missing files issue.
chipx86
#14 chipx86 
Old repos shouldn't be a problem at all. The sort of behavior you're seeing should never happen under any circumstances without corruption or some custom database manipulation being involved.
david
#15 david