I think we need to improve how we handle Bitbucket requests, potentially through better caching, request deduplication, or reducing unnecessary polling.

I am currently hitting Bitbucket's request limits almost daily on my Jenkins instance, which results in a complete work stoppage and repeated fire drills:

https://support.atlassian.com/bitbucket-cloud/docs/api-request-limits/

Can we investigate where all of these requests are coming from and whether the plugin is making duplicate, excessive, or unnecessary calls?

In particular, I am seeing the 60,000 requests/hour Git operations limit being exhausted. That is an extremely high number of requests for a single hour, and it makes me concerned that we may have a request loop, excessive polling, missing caching, or some other issue causing significantly more Bitbucket traffic than expected.

We should also look at adding better observability around this. Right now, I am not sure how to prove from the plugin side exactly which operations are generating these requests or how frequently they are occurring.

Ideally, I think we need to:

• Identify which plugin operations are generating the Bitbucket requests.
• Add metrics or logging so we can measure request volume by operation/endpoint.
• Determine whether requests can be cached or deduplicated.
• Look for polling loops or repeated repository/branch discovery operations.
• Respect Bitbucket rate-limit responses and implement appropriate backoff.
• Reduce unnecessary calls before we get close to the limit rather than waiting until Bitbucket starts rejecting requests.

Hitting 60,000 Git operations in a rolling one-hour window should be something we can explain. If that volume is legitimate, we need to understand why. If it isn't, we need enough instrumentation in the plugin to identify where the excess requests are coming from.