The GitHub API rate limit was the wrong diagnosis for the failing Setup PHP step, so this reverts #175 — the 1Password-backed token and the mirrored composite action — leaving the workflows as they were.
Why it is not the rate limit
I timed every Setup PHP step across runs 454–523:
PHP
attempts
range
failures
8.1
6
26–40s
0
8.2
6
29–41s
0
8.3
26
143–1273s
2
Three things rule the rate limit out:
It sorts by PHP version, and a throttle cannot. The 8.1, 8.2 and 8.3 jobs run in the same fan-out, and so share an egress address and a rate limit bucket. 8.1 and 8.2 have never once been slow or failed.
Run 523 is the direct refutation. It is the first run carrying the token. The token resolved and the verify step passed, and Setup PHP still took 749s on kallone and 408s on eris.
It predates the story. 8.3 was already sitting at ~145s on 30 July (run 454), long before any rate limit pressure.
It is also not cluster-specific — median 8.3 setup is 382s on eris, 452s on kallone, 151s on nemesis, versus ~35s for 8.1/8.2 everywhere.
What is actually happening
PHP 8.3 takes a different, much slower install path on these arm64 runners — a ~145s floor against ~35s for the other two, with a long tail that occasionally crosses the step timeout and reports only Could not setup PHP 8.3 after twelve minutes of silence. That reads like a hang, which is what made a throttle a believable guess.
Worth noting: 8.3 is the native PHP of the runner image's Ubuntu release, which is the plausible reason it alone lands on the apt/PPA path instead of the prebuilt-tarball path the other two get. I could not confirm that inside the runner, so treat it as the leading hypothesis rather than a settled cause. Filing it separately.
Tests
composer test — 915 tests, 2592 assertions, OK
composer lint — no errors
composer cs — clean
No changelog entry: CI-only, nothing user-visible.
The GitHub API rate limit was the wrong diagnosis for the failing Setup PHP step, so this reverts #175 — the 1Password-backed token and the mirrored composite action — leaving the workflows as they were.
## Why it is not the rate limit
I timed every Setup PHP step across runs 454–523:
| PHP | attempts | range | failures |
|-----|----------|-------|----------|
| 8.1 | 6 | 26–40s | 0 |
| 8.2 | 6 | 29–41s | 0 |
| 8.3 | 26 | 143–1273s | 2 |
Three things rule the rate limit out:
1. **It sorts by PHP version, and a throttle cannot.** The 8.1, 8.2 and 8.3 jobs run in the same fan-out, and so share an egress address and a rate limit bucket. 8.1 and 8.2 have never once been slow or failed.
2. **Run 523 is the direct refutation.** It is the first run carrying the token. The token resolved and the verify step passed, and Setup PHP still took 749s on kallone and 408s on eris.
3. **It predates the story.** 8.3 was already sitting at ~145s on 30 July (run 454), long before any rate limit pressure.
It is also not cluster-specific — median 8.3 setup is 382s on eris, 452s on kallone, 151s on nemesis, versus ~35s for 8.1/8.2 everywhere.
## What is actually happening
PHP 8.3 takes a different, much slower install path on these arm64 runners — a ~145s floor against ~35s for the other two, with a long tail that occasionally crosses the step timeout and reports only `Could not setup PHP 8.3` after twelve minutes of silence. That reads like a hang, which is what made a throttle a believable guess.
Worth noting: 8.3 is the native PHP of the runner image's Ubuntu release, which is the plausible reason it alone lands on the apt/PPA path instead of the prebuilt-tarball path the other two get. I could not confirm that inside the runner, so treat it as the leading hypothesis rather than a settled cause. Filing it separately.
## Tests
- `composer test` — 915 tests, 2592 assertions, OK
- `composer lint` — no errors
- `composer cs` — clean
No changelog entry: CI-only, nothing user-visible.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks
The GitHub API rate limit was the wrong diagnosis, so this reverts the
1Password-backed token added in #175 along with the mirrored composite
action, leaving the workflows as they were.
Timing every Setup PHP step across runs 454-523 rules the rate limit out.
PHP 8.1 and 8.2 install in 26-41 seconds, 12 for 12, never once failing.
PHP 8.3 has never finished in under 143 seconds and ranges up to 1273,
with two outright failures. Those jobs share a fan-out, and so an egress
address and a rate limit bucket, with the 8.1 and 8.2 jobs that are never
touched. A throttle could not sort itself by PHP version that way.
Run 523, the first to carry the token, is the direct refutation: the
token resolved and verified, and Setup PHP still took 749 seconds on
kallone and 408 on eris. The 8.3 penalty also predates the whole story,
sitting at ~145 seconds back on 30 July.
What is left is a slow path specific to 8.3 on these arm64 runners, whose
long tail sometimes crosses the step timeout and reports the unhelpful
"Could not setup PHP 8.3". That is worth fixing on its own terms rather
than behind a token that was never in the path.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The GitHub API rate limit was the wrong diagnosis for the failing Setup PHP step, so this reverts #175 — the 1Password-backed token and the mirrored composite action — leaving the workflows as they were.
Why it is not the rate limit
I timed every Setup PHP step across runs 454–523:
Three things rule the rate limit out:
It is also not cluster-specific — median 8.3 setup is 382s on eris, 452s on kallone, 151s on nemesis, versus ~35s for 8.1/8.2 everywhere.
What is actually happening
PHP 8.3 takes a different, much slower install path on these arm64 runners — a ~145s floor against ~35s for the other two, with a long tail that occasionally crosses the step timeout and reports only
Could not setup PHP 8.3after twelve minutes of silence. That reads like a hang, which is what made a throttle a believable guess.Worth noting: 8.3 is the native PHP of the runner image's Ubuntu release, which is the plausible reason it alone lands on the apt/PPA path instead of the prebuilt-tarball path the other two get. I could not confirm that inside the runner, so treat it as the leading hypothesis rather than a settled cause. Filing it separately.
Tests
composer test— 915 tests, 2592 assertions, OKcomposer lint— no errorscomposer cs— cleanNo changelog entry: CI-only, nothing user-visible.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks
thatguygriff referenced this pull request2026-08-20 17:30:08 +00:00