3601: Diffs disappearing and replaced with "This is an empty file."

andrew******@rockwellc********** (Google Code) (Is this you? Claim this profile.)
chipx86
 chipx86
Jan. 13, 2015
3660 
What version are you running?
reviewboard 2.0.5
rbtools 0.6.2

What's the URL of the page containing the problem?
Internal company site

What steps will reproduce the problem?
1. Post a review with file modifications, view the diff
2. Wait a few minutes
3. view the diff again (refresh in web browser)

What is the expected output? What do you see instead?
Many of the files that showed diffs now say "This is an empty file."

What operating system are you using? What browser?
Posted under ubuntu 14.04, viewed with chrome 37.0.2062.124 m on windows 7

Please provide any additional information below.
Creating a new review with the same files has the same issue.
Reposting the diffs has the same issue
#1 andrew******@rockwellc********** (Google Code) (Is this you? Claim this profile.) 
Using git as scm
Issue corrects itself if using rbt post --tracking-branch instead of rbt post --parent
#2 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
We are experiencing the same issue, although the diff disappears even when we use for example rbt post HEAD, i.e. we post a review request for just a single commit.

Review Board 2.0.8
RBTools 0.6.2
#3 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
Hmm, actually now I can see that RB is showing a different hash from the commits I posted. Maybe I actually amended the commit later and now RB cannot find it any more...
#4 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
Actually it is happening even though the commit in RB is the same as the commit on GitHub... :-/
#5 Tim.K******@fieldaw******* (Google Code) (Is this you? Claim this profile.) 
This has started happening for us too, but the diff is visible for a period of time. Shortly after publishing the review the diff disappears. It's very strange.
#6 Tim.K******@fieldaw******* (Google Code) (Is this you? Claim this profile.) 
Reviewboard 2.0.11
RBTools 0.6.3
OS: Amazon Linux AMI release 2014.09
Browsers: Safari, Firefox and Chrome

commands where this has happened:
rbt post HEAD
rbt post HEAD^ HEAD
rbt post SHA1 SHA2
rbt post --parant=another/branch
#7 mat****@salsita******** (Google Code) (Is this you? Claim this profile.) 
Yes, that's exactly the behavior we were observing. FWIW we ended up creating a new repo in RB for the project (pointing at the same GitHub repo) and so far we haven't seen the problem again.
david
#8 david
chipx86
#9 chipx86 
In all these cases, were these files newly added in a prior commit somewhere between the tracking branch (defaulting to origin/master) and HEAD?

If so, I've figured out the cause.
  • +NeedInfo
  • -Priority-Medium
    +Priority-High
    +Milestone-Release2.0.x
    +Component-DiffViewer
  • +chipx86
chipx86
#10 chipx86 
Also, did this happen just when viewing interdiffs only, or any time viewing the diff?
#11 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
For us it was any time viewing the diff.
chipx86
#12 chipx86 
What about the file? Was it added in a prior commit somewhere between origin/master and HEAD?
chipx86
#13 chipx86 
I ask about the interdiff, because the only case where the conditions match up to cause the bug I'm seeing in the code is when viewing interdiffs.

Do you still have access to review requests with this problem?
#14 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
I would have to go through the RRs and try to find one.

Anyway, we use a CLI utility wrapping rbt to post RRs. Most of the time it is used in the following way:
1) Create a local feature branch on top of branch "develop". That branch can be pushed as well, not sure if that is important.
2) Code, code, code, commit, commit, commit.
3) Call the CLI utility, which in turn calls `rbt post HASH` for every commit that is on the feature branch but not on develop. When this is called, the new commits are usually not pushed yet (not sure how important that is). As I said, the feature branch might be tracking a remote branch or not.

Let me know if you need more info.
chipx86
#15 chipx86 
That meets the criteria for how to reproduce the bug. The only missing step is that, from what I can tell, it should only be possible to hit this for interdiffs.

Or, alternatively, for files that only contained leading or trailing whitespace changes. Any chance that that was a common factor?
#16 ond****@salsita******** (Google Code) (Is this you? Claim this profile.) 
I unfortunately don't manage to find any broken RR. The repo that had these issues was deleted and I don't remember encountering this recently (now using RB 2.0.11). And anyway, I always used rbt -r to update the RR, to fix the broken file. That was usually after some time when the commit was already pushed and stuff. Don't remember seeing the problem appear again after fixing the RR with rbt -r...
chipx86
#17 chipx86 
Okay. I appreciate the info! Based on my tests, I'm fairly confident i've now tracked down the causes of this bug. The good news is that files were never deleted or made empty, they just had some bad calculated state that could occur after the first viewing in certain cases.

We'll have a fix in for 2.0.13. I'd appreciate people trying to patch after it's up for review.
  • -NeedInfo
    +Confirmed
chipx86
#18 chipx86 
To further clarify, the empty state would happen in the following cases:

1) Showing interdiffs between two diffs containing a newly added file, when the interdiff should only show replaced lines.
2) Same as #1, but when the diff from a commit that was based on a parent commit that was newly introduced in the branch and not yet pushed upstream (due to a separate issue where the source revision was replaced with the marker for "new file").
3) Same as #2, but with files that haven't actually changed between those revisions.
chipx86
#19 chipx86 
Fixed in release-2.0.x (6d2a0b8). This will go into Review Board 2.0.13.
  • -Confirmed
    +Fixed