Summary

On the pull request overview page, the date on the '<User> updated the pull request' can be before the timestamp of the commit(s) mentioned.

Environment

• MySQL 5.6+ as database

Steps to Reproduce

NA

Expected Results

The application always shows a coherent time in the user interface.

Actual Results

The date on the '<User> updated the pull request' is before the timestamp of the commit(s) mentioned.

The below exception is thrown in the atlassian-bitbucket.log file:

WARN  [pull-request-rescoping:thread-1]  c.a.s.i.p.r.PullRequestRescopeChain PKEY/slug[123]#1090: A gap was detected in the pull request history: {gap from-ref: {old-hash: 99121efb1cb7e07c225ea8186803e721844f5a3b, new-hash: a86c3e241e845d4a02663f43b3d747ae300f8ab3}, to-ref: unchanged}. Attributing the scope change to user the username and setting the rescope date to Fri Jun 03 10:30:04 AEST 2016 based on known changes

In addition, on the pull request overview page, the date on the '<User> updated the pull request' can be before the timestamp of the commit(s) mentioned.

Notes

When a user pushes changes to a repository, all open pull requests affected by this push are updated asynchronously in the background. The relevant information (what branches were updated) from the push is stored in the database. This information includes the timestamp.

The timestamp is used during the updating of the pull requests to determine whether the change has already been processed. On MySQL, timestamps are recorded with a 1s resolution and actual values are truncated or rounded. This rounding can cause the rescoping algorithm to incorrectly determine that the push has already been processed and discard the information.

In a later phase, it is discovered that the pull request is out of date (it's branches have changed), but that no known push can explain the change. In other words, a 'gap' is detected and an artificial activity is created to explain the gap.