Work around 403s when synchronizing the mailing list mirror #18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
webstech
reviewed
Sep 29, 2025
Authorization is hard. So hard, in fact, that it seems that (maybe due to incorrect optimizations?) pushes to GitHub with an installation access token that has _just_ been obtained sometimes fail with a 403, even though it seems that a re-run "fixes" the problem. The first instances of this problem was https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/runs/17543752351/job/49820347084#step:6:11 on Sep 8, 2025, 9:52 AM GMT+2: Run git push ***github.com/$TARGET_GITHUB_REPOSITORY lore-$LORE_EPOCH remote: Permission to gitgitgadget/git-mailing-list-mirror.git denied to gitgitgadget[bot]. fatal: unable to access 'https://github.com/gitgitgadget/git-mailing-list-mirror/': The requested URL returned error: 403 Error: Process completed with exit code 128. This happened relatively shortly after I had merged gitgitgadget#12 on Sep 5, 2025, 7:55 AM GMT+2, and there were 30 such occurrences of denied pushes due to apparently not-yet-valid installation tokens in https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/workflows/sync-mailing-list-mirror.yml (which isn't bad, given that there have been 1,892 runs of that workflow since Sep 5, 8:44 AM GMT+2, as of time of writing). So it _might_ seem as if the flake has something to do with this change, but then, it occurs too rarely to be _caused_ by that change, _and_ it seems to happen a tad more frequently than once a day _but_ started 3 days after merging that PR. As I stated above, I have come to the conclusion that it is something on GitHub's side where they changed something on their side that _sometimes_ lets installation access tokens be _not quite ready for pushing_ for a little while right after the tokens have been issued. Corroborating evidence for that suspicion are the 8 occurrences of the same issue in the sister repository I established for Cygwin: https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/workflows/sync-mailing-list-mirror.yml And in that repository, essentially the same workflow had been running a quite a few days longer _without_ any issues, more concretely, it has done its job without problems since Aug 30, 2025, 6:40 PM GMT+2 in https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/runs/17346140096 until it failed for the first time on Sep 22, 2025, 7:24 PM GMT+2 in https://github.com/cygwingitgadget/gitgitgadget-workflows/actions/runs/17923242729/job/50963073473#step:6:11 with the same 403. Let's just work around that by trying again to push, if necessary a couple of times (with a back-off strategy). Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
work-around-403s
branch
from
a660f5b to
d41c899
Compare
webstech
reviewed
Sep 29, 2025
|
For the record: the 403 happened again. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Authorization is hard. So hard, in fact, that it seems that (maybe due to incorrect optimizations?) pushes to GitHub with an installation access token that has just been obtained sometimes fail with a 403, even though it seems that a re-run "fixes" the problem.
The first instances of this problem happened on Sep 8, 2025, 9:52 AM GMT+2:
This happened relatively shortly after I had merged #12 on Sep 5, 2025, 7:55 AM GMT+2, and there were 30 such occurrences of denied pushes due to apparently not-yet-valid installation tokens in https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/actions/workflows/sync-mailing-list-mirror.yml (which isn't bad, given that there have been 1,892 runs of that workflow since Sep 5, 8:44 AM GMT+2, as of time of writing).
So it might seem as if the flake has something to do with this change, but then, it occurs too rarely to be caused by that change, and it seems to happen a tad more frequently than once a day but started 3 days after merging that PR. As I stated above, I have come to the conclusion that it is something on GitHub's side where they changed something on their side that sometimes lets installation access tokens be not quite ready for pushing for a little while right after the tokens have been issued.
Corroborating evidence for that suspicion are the 8 occurrences of the same issue in the sister repository I established for Cygwin. And in that repository, essentially the same workflow had been running a quite a few days longer without any issues, more concretely, it has done its job without problems since Aug 30, 2025, 6:40 PM GMT+2 until it failed for the first time on Sep 22, 2025, 7:24 PM GMT+2 with the same 403.
Let's just work around that by trying again to push, if necessary a couple of times (with a back-off strategy).