[BSERV-9955] Pull requests are declined or updates are attributed to the wrong user

Type: Bug
Resolution: Fixed
Priority: Medium
Fix Version/s: 5.3.0, 4.14.8, 5.0.7, 5.1.5, 5.2.3
Affects Version/s: 4.14.0, 5.0.0, 4.13.1, 5.1.0, 5.2.0
Component/s: Pull Requests
Labels:
None

Symptom Severity:
Severity 2 - Major
UIS:
24
Bug Fix Policy:
View Atlassian Server bug fix policy

In Bitbucket 4.13, the mechanism for resolving refs (determining the current commit the branch/tag references) was refactored. The new implementation does not properly handle concurrent updates to the packed-refs, which can result in the ref not resolving properly. When this happens, Bitbucket incorrectly concludes that the branch or tag does not exist.

Symptoms

Example stack trace:

2017-07-17 11:40:56,120 WARN  [pull-request-rescoping:thread-1]  c.a.s.i.scm.git.ref.PackedRefDb Problem reading from packed-refs file /data/bitbucket/shared/data/repositories/12345/packed-refs (FileAlreadyExistsException: /data/bitbucket/shared/data/repositories/12345/packed-refs)
java.nio.file.FileAlreadyExistsException: /data/bitbucket/shared/data/repositories/12345/packed-refs
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
	at java.nio.file.Files.newByteChannel(Files.java:361)
	at java.nio.file.Files.newByteChannel(Files.java:407)
	at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
	at java.nio.file.Files.newInputStream(Files.java:152)
	at java.nio.file.Files.newBufferedReader(Files.java:2784)
	at java.nio.file.Files.newBufferedReader(Files.java:2816)
	at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.initialize(PackedRefDb.java:309)
	at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.getNext(PackedRefDb.java:253)
	at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.hasNext(PackedRefDb.java:237)
	at com.atlassian.stash.internal.scm.git.ref.PackedRefDb.internalResolve(PackedRefDb.java:114)
	at com.atlassian.stash.internal.scm.git.ref.PackedRefDb.resolve(PackedRefDb.java:71)
	at com.atlassian.stash.internal.scm.git.ref.CompositeGitRefDb.resolve(CompositeGitRefDb.java:109)
	at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.internalCall(ResolveGitRefDbCommand.java:54)
	at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.internalCall(ResolveGitRefDbCommand.java:23)
	at com.atlassian.stash.internal.scm.git.command.refdb.AbstractGitRefDbCommand.call(AbstractGitRefDbCommand.java:49)
	at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.call(ResolveGitRefDbCommand.java:43)
	at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.call(ResolveGitRefDbCommand.java:23)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.resolveRefs(DefaultPullRequestRescopeService.java:352)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.resolveRefs(DefaultPullRequestRescopeService.java:331)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.setTargetStateOnRescopeChains(DefaultPullRequestRescopeService.java:365)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.rescopeInternal(DefaultPullRequestRescopeService.java:281)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.lambda$rescope$0(DefaultPullRequestRescopeService.java:117)
	at com.atlassian.stash.internal.user.DefaultEscalatedSecurityContext.call(DefaultEscalatedSecurityContext.java:54)
	at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.rescope(DefaultPullRequestRescopeService.java:116)
	at com.atlassian.stash.internal.pull.rescope.PullRequestRescopeBucketProcessor.process(PullRequestRescopeBucketProcessor.java:158)
	at com.atlassian.stash.internal.concurrent.HazelcastBucketedExecutor$BucketProcessingBootstrapper.run(HazelcastBucketedExecutor.java:125)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.lang.Thread.run(Thread.java:745)
	... 13 frames trimmed

The problem is most visible when pull requests are updated as a result of an update to the source or target branch. This can result in:

the pull request being declined (because the source/target branch appeared to be deleted)
the pull request incorrectly reporting that multiple commits were removed from the pull request. This happens because the loose ref in the repository did not resolve, but an older version of the ref was present in packed-refs. To the pull request rescope process, it appears that the branch was reset to the older hash.

Workaround

If the pull request was declined, it can be reopened.
If the pull request displays the incorrect scope, decline and reopen the pull request to refresh it.

is cloned from

BSERV-9553 Pull requests are declined or updates are attributed to the wrong user

Closed

Owen made changes - 10/Apr/2019 6:47 AM

Workflow

Original: Stash Workflow - Restricted [ 2412769 ]

New: JAC Bug Workflow v3 [ 3137300 ]

Owen made changes - 24/Oct/2018 5:05 AM

Symptom Severity

Original: Major [ 14431 ]

New: Severity 2 - Major [ 15831 ]

Bryan Turner (Inactive) made changes - 12/Aug/2017 12:57 AM

Fix Version/s		New: 5.3.0 [ 72810 ]
Fix Version/s		New: 4.14.8 [ 73053 ]
Fix Version/s		New: 5.0.7 [ 73054 ]
Fix Version/s		New: 5.1.5 [ 73055 ]
Fix Version/s		New: 5.2.3 [ 73056 ]
Resolution		New: Fixed [ 1 ]
Status	Original: To be reviewed [ 10026 ]	New: Closed [ 6 ]

Bugfix Automation Bot made changes - 04/Aug/2017 5:59 PM

UIS

Original: 1

New: 24

Bugfix Automation Bot made changes - 02/Aug/2017 9:11 PM

UIS

New: 1

Michael Heemskerk (Inactive) made changes - 26/Jul/2017 1:00 PM

Status

Original: In Progress [ 3 ]

New: To be reviewed [ 10026 ]

Michael Heemskerk (Inactive) made changes - 26/Jul/2017 1:00 PM

Status

Original: Open [ 1 ]

New: In Progress [ 3 ]

Michael Heemskerk (Inactive) made changes - 26/Jul/2017 11:22 AM

Fix Version/s	Original: 4.14.0 [ 66341 ]
Fix Version/s	Original: 4.13.1 [ 66740 ]

Michael Heemskerk (Inactive) made changes - 25/Jul/2017 2:45 PM

Status

Original: Needs Triage [ 10030 ]

New: Open [ 1 ]

Michael Heemskerk (Inactive) made changes - 25/Jul/2017 2:45 PM

Description

Original: In Bitbucket 4.13, the mechanism for resolving refs (determining the current commit the branch/tag references) was refactored. The new implementation does not properly handle concurrent updates to the {{packed-refs}}, which can result in the ref not resolving properly. When this happens, Bitbucket incorrectly concludes that the branch or tag does not exist.

h3. Symptoms

Example stack trace:
{noformat}

{noformat}

The problem is most visible when pull requests are updated as a result of an update to the source or target branch. This can result in:
* the pull request being declined (because the source/target branch appeared to be deleted)
* the pull request incorrectly reporting that multiple commits were removed from the pull request. This happens because the loose ref in the repository did not resolve, but an older version of the ref was present in {{packed-refs.}} To the pull request rescope process, it appears that the branch was reset to the older hash.

h3. Workaround
* If the pull request was declined, it can be reopened.
* If the pull request displays the incorrect scope, decline and reopen the pull request to refresh it.

New: In Bitbucket 4.13, the mechanism for resolving refs (determining the current commit the branch/tag references) was refactored. The new implementation does not properly handle concurrent updates to the {{packed-refs}}, which can result in the ref not resolving properly. When this happens, Bitbucket incorrectly concludes that the branch or tag does not exist.

h3. Symptoms

Example stack trace:
{noformat}
2017-07-17 11:40:56,120 WARN [pull-request-rescoping:thread-1] c.a.s.i.scm.git.ref.PackedRefDb Problem reading from packed-refs file /data/bitbucket/shared/data/repositories/12345/packed-refs (FileAlreadyExistsException: /data/bitbucket/shared/data/repositories/12345/packed-refs)
java.nio.file.FileAlreadyExistsException: /data/bitbucket/shared/data/repositories/12345/packed-refs
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
at java.nio.file.Files.newInputStream(Files.java:152)
at java.nio.file.Files.newBufferedReader(Files.java:2784)
at java.nio.file.Files.newBufferedReader(Files.java:2816)
at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.initialize(PackedRefDb.java:309)
at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.getNext(PackedRefDb.java:253)
at com.atlassian.stash.internal.scm.git.ref.PackedRefDb$PackedRefIterator.hasNext(PackedRefDb.java:237)
at com.atlassian.stash.internal.scm.git.ref.PackedRefDb.internalResolve(PackedRefDb.java:114)
at com.atlassian.stash.internal.scm.git.ref.PackedRefDb.resolve(PackedRefDb.java:71)
at com.atlassian.stash.internal.scm.git.ref.CompositeGitRefDb.resolve(CompositeGitRefDb.java:109)
at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.internalCall(ResolveGitRefDbCommand.java:54)
at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.internalCall(ResolveGitRefDbCommand.java:23)
at com.atlassian.stash.internal.scm.git.command.refdb.AbstractGitRefDbCommand.call(AbstractGitRefDbCommand.java:49)
at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.call(ResolveGitRefDbCommand.java:43)
at com.atlassian.stash.internal.scm.git.command.refdb.ResolveGitRefDbCommand.call(ResolveGitRefDbCommand.java:23)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.resolveRefs(DefaultPullRequestRescopeService.java:352)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.resolveRefs(DefaultPullRequestRescopeService.java:331)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.setTargetStateOnRescopeChains(DefaultPullRequestRescopeService.java:365)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.rescopeInternal(DefaultPullRequestRescopeService.java:281)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.lambda$rescope$0(DefaultPullRequestRescopeService.java:117)
at com.atlassian.stash.internal.user.DefaultEscalatedSecurityContext.call(DefaultEscalatedSecurityContext.java:54)
at com.atlassian.stash.internal.pull.rescope.DefaultPullRequestRescopeService.rescope(DefaultPullRequestRescopeService.java:116)
at com.atlassian.stash.internal.pull.rescope.PullRequestRescopeBucketProcessor.process(PullRequestRescopeBucketProcessor.java:158)
at com.atlassian.stash.internal.concurrent.HazelcastBucketedExecutor$BucketProcessingBootstrapper.run(HazelcastBucketedExecutor.java:125)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.lang.Thread.run(Thread.java:745)
... 13 frames trimmed

{noformat}

The problem is most visible when pull requests are updated as a result of an update to the source or target branch. This can result in:
* the pull request being declined (because the source/target branch appeared to be deleted)
* the pull request incorrectly reporting that multiple commits were removed from the pull request. This happens because the loose ref in the repository did not resolve, but an older version of the ref was present in {{packed-refs.}} To the pull request rescope process, it appears that the branch was reset to the older hash.

h3. Workaround
* If the pull request was declined, it can be reopened.
* If the pull request displays the incorrect scope, decline and reopen the pull request to refresh it.

Assignee:: Michael Heemskerk (Inactive)

Reporter:: Michael Heemskerk (Inactive)

Affected customers:: 6 This affects my team

Watchers:: 6 Start watching this issue

Created:: 25/Jul/2017 2:41 PM

Updated:: 24/Oct/2018 5:05 AM

Resolved:: 12/Aug/2017 12:57 AM

Bitbucket Data Center

Details

Description

Symptoms

Workaround

Attachments

Issue Links

Forms

Activity

People

Dates