Issue Summary

When a repository is hosted on a sidecar or remote mesh nodes, an uncached clone or a fetch operation for a repository shows inaccurate error when a hosting ticket could not be granted by the system.

This is reproducible on Data Center: yes.

Steps to Reproduce

1. Set up Bitbucket with sidecar enabled or repository migrated to remote mesh node.
2. Ensure all the hosting tickets are exhausted by a lot of long running clone or fetch operations and the new hosting operations start queueing up for hosting tickets and eventually time out.
3. Execute git clone for a repository so that it times out waiting for a hosting ticket.

The following config may facilitate reproducing the issue:

throttle.resource.scm-hosting.strategy=fixed
throttle.resource.scm-hosting.fixed.limit=2
throttle.resource.scm-hosting.timeout=10

Push a large repository that takes a few minutes to clone. Run three clones whilst constantly pushing to the repository. The first two will proceed while the third will fail after 10s due to the inability to acquire a hosting ticket (the failed clone has to be uncached).

Expected Results

Proper error is shown:

$ git clone http://localhost:7990/bitbucket/scm/project_1/rep_1.git
Cloning into 'rep_1'...
remote: Server busy
remote: Bitbucket is currently under heavy load and is not able to service your
remote: request. Please wait briefly and try your request again.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: fetch-pack: invalid index-pack output 

Actual Results

The following error is given, which does not accurately depict the throttling behavior:

$ git clone ssh://git@localhost:7999/project_1/rep_1.git
Cloning into 'rep_1'...
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Workaround

Currently there is no known workaround for this behaviour. A workaround will be added here when available.