Hello everyone,
I'm writing, in case anyone has encountered my issues running Laravel Shift(s) for their repositories.
I have a multi-repo project, for every repository I need to run Laravel Shift which pulls a branch, commits changes, opens a PR and adds comment to the PR. All of it trough the API.
What I know so far:
Bitbucket has a rate limit of 1000 requests (sliding window). Up to 10k but we probably don't exceed the 1000.
The connection between Laravel Shift and Bitbucket API is made trough app authorization.
I've confirmed my connected Bitbucket account can read/write on the repositories.
The problem(s):
Even if I wait for a Shift to finish, give it some time to cool off and then start a new one, laravel shift gets 429 errors.
In the latest case I even get 403 Forbidden. (I double checked the workspace/repository name for typos)
Those 2 error codes were provided by the Laravel Shift Support I don't have a way to monitor the Shift jobs themself.
I also don't know of a way to monitor what is the current usage in the sliding window for Bitbucket or how many requests does 1 Shift make
Or even if there are any audit logs that can be checked by a Bitbucket workspace admin.
Does anyone have suggestions, how do I approach those 2 issues?
Welcome @milko_ivanov
From what you've described if I correctly understand, this sounds more like an API rate limiting issue than a repository permission problem.
Bitbucket Cloud applies rate limits to authenticated API requests, and the limit is tracked against the identity/token making the requests. A single Laravel Shift run may be making many API calls behind the scenes (for example, reading repository data, creating commits, opening PRs, and adding comments), so running multiple shifts across several repositories can consume the available quota quickly.
A few things I would check:
The 403 response is interesting because after hitting rate limits some integrations can surface different errors depending on how they handle failed API calls, so I would first verify whether the underlying response is still related to rate limiting.
Also, do you run these shifts sequentially or in parallel across multiple repositories? That detail could make a big difference here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.