Issue Summary

DefaultPullRequestRescopeService.deleteHandledRescopeRequests() states the intended contract:

// Rescope requests older than 1 day are deleted regardless of whether they are complete or not. This is done
// to ensure that rescope requests that consistently trigger failure are not retried indefinitely. Note that
// any rescope is attempted at least MAX_RESCOPE_ATTEMPTS.

That statement is not being met. The expiry mechanism lives inside deleteHandledRescopeRequests(), which is only reached at the end of a rescope pass that completes.

If a "graceful" failure occurs then deleteHandledRescopeRequests() can get called. But if determineRescopes() or applyRescopes() throws an exception then rescopeInternal() is exited before deleteHandledRescopeRequests() is called. A practical example of this is when the Mesh BatchRescope call fails, perhaps due to RESOURCE_EXHAUSTED or DEADLINE_EXCEEDED (e.e. once it exceeds the 300s bulk rescope budget). In that case every request is retained, including those older than a day. Each subsequent pass replays a larger backlog, so the requests are retried indefinitely and the repository likely never resumes successful rescoping.

This has been reproduced on Bitbucket 10.2.5, but the code is essentially unchanged since Bitbucket 4.5.1, so I'll see that as the likely first affected version. It is worth noting however that the triggers for exceptions being thrown have changed, with large changes occurring in 8.0.0 (with the addition of the sidecar).

Expected Results

Rows older than 1 day are removed from sta_pr_rescope_request when a rescope attempt finishes.

Actual Results

A rescope attempt runs and fails, and rows are not removed from sta_pr_rescope_request when a rescope attempt finishes.

Workaround

Manually delete rows from sta_pr_rescope_request that have a created_timestamp greater than 1 day old.