[Sreini]

Makes the PHP CI matrix fully green. Three unrelated breakages, none caused by any commit in this repo — all three are environment drift that landed while the repo sat still.

No composer.lock is involved, and committing one would not have helped. More on that at the bottom.

1. phpstan — pinned

Red since April, and the reported errors kept changing: in September it flagged two curl_getinfo stub errors at Client.php:156-157; it now flags two entirely different ones. composer.phpstan.json asked for ^2.1 with its lock gitignored, so every run resolved whatever was newest. Pinned to an exact version.

The two findings that remain under 2.3.4 are correct, not false positives:

127  Comparison operation ">=" between 0|1 and 0 is always true
199  Unreachable statement - code above always terminates

Every path through the Client::request retry loop returns, continues or throws, and a continue only happens while $retries > 0. So $retries is only ever 0 or 1 at the condition check, the loop never ends by exhausting its bound, and the trailing max retries exceeded throw is dead today. Both look deliberate — the bound documents the retry budget, the throw guards a future fall-through path — so they are recorded in ignoreErrors with that reasoning rather than deleting working retry logic. Say the word if you would rather drop the throw and simplify the loop.

2. macOS — the workflow was running twice and racing itself

This was the real cause, and it is fixed.

on: [push, pull_request] fired two complete runs for every push to a PR branch. On commit ca20989 the two were created three seconds apart, and their ten macOS jobs all started within twenty seconds of each other, each invoking setup-php against the same runner tool cache:

run	macOS jobs
pull_request	5/5 pass
push	5/5 fail — composer: command not found

Identical commit, identical workflow, opposite outcomes. setup-php reported success but left composer off the PATH, which is what losing a race over the tool cache looks like. The 10-minute timeouts seen earlier are very likely the same contention, ten jobs building PHP simultaneously — which is also why raising timeout-minutes appeared to help without being the actual fix.

Restricting push to master gives PR branches exactly one run, and a concurrency group cancels superseded runs on rapid pushes. This halves CI spend per PR as a side effect.

Integration_tests was gated on github.event_name == 'push', which previously included PR branches. With push now master-only that would have silently dropped integration coverage from PRs, so the condition is widened to master pushes plus same-repo pull requests — coverage and API quota use unchanged. Fork PRs stay excluded because they never receive TINIFY_KEY.

timeout-minutes is still raised from 10 to 30, now as genuine headroom rather than a fix.

3. PHP 5.4 on Windows — an upstream composer regression

composer install exits 1 on PHP 5.4 under Windows having printed nothing at all, even with display_errors=On and error_reporting=-1, and without creating vendor/. The last thing it logs under -vvv is its first request to packagist.

Bisected on windows-latest / PHP 5.4, checking whether vendor/ actually appears rather than trusting the step's exit status:

composer	result
2.2.22 – 2.2.30	vendor/ present — install OK
2.2.31	no vendor/ — install FAILED

Bisected across the whole range, not just two points: only the newest release is affected.

composer 2.2.31 was released 2026-10-29. These jobs began failing 2026-10-31 and passed throughout September. So this is a regression inside the 2.2 LTS line, not anything about this project — composer:2.2 resolves to the newest 2.2.x, which is how it arrived without any commit landing here.

Fixed by pinning composer:2.2.30 on the 5.x jobs — the highest working release. Nothing is excluded from the matrix.

Pinning high matters: every composer advisory in this line is patched at 2.2.24 or earlier (CVE-2023-43655 in 2.2.22, CVE-2024-24821 in 2.2.23, CVE-2024-35241/35242 in 2.2.24), so 2.2.30 gives up no security fix while avoiding the regression. The pin applies only to the 5.x jobs; 7.4/8.0/8.5 stay on composer:v2.

2.2.31 is currently the newest 2.2.x, so there is no upstream fix to wait for, and composer 2.3 raised its floor to PHP 7.2.5 so the 2.2 line is the only option for PHP 5.x at all. Worth revisiting if a 2.2.32 ships.

Worth recording, because it is misleading: PHP 5.4's streams OpenSSL really is 0.9.8 with no TLS 1.1/1.2 support, and its transport list is ssl, sslv3, sslv2, tls with tls:// to packagist failing. That makes a TLS explanation fit the silent death neatly, and an earlier revision of this branch acted on it. It is not the cause: composer uses curl, which links a separate OpenSSL 1.0.2u, reaches packagist and returns HTTP 200, and composer diagnose reports https connectivity to packagist: OK on that same runtime. Memory, the PowerShell default shell, the composer validate step and matrix contention were each tested and ruled out too.

Also added: an explicit test -d vendor check after install. Several probes during this investigation reported success while installing nothing, and the test step would otherwise be the first thing to notice.

Upstream: this is a composer bug worth reporting, and the bisect pins it to a single release — 2.2.30 works, 2.2.31 does not.

Result

One run per commit instead of two, and 21/21 green with nothing excluded: 15/15 Unit_tests (every PHP version on all three OSes) and 6/6 Integration_tests. PHPStan passes.

Why not a committed composer.lock

It came up, so worth recording. A single lock cannot span 5.4–8.5. composer install uses a lock verbatim, so whichever PHP version generates it becomes the only one that can install it — a lock built on 8.3 pins doctrine/instantiator 2.0.0 (requires php ^8.1), which then fails on 5.4, 5.6, 7.4 and 8.0. The wide phpunit: ^4.8 || … || ^9.3 constraint exists precisely so each PHP version resolves its own compatible phpunit, and a lock collapses that to one set. Committing one would have taken this matrix from one broken job to four.

Note on history

Two temporary diagnostic commits (display_errors, composer -vvv) are present and explicitly reverted by the final commit, rather than squashed — a force-push was not available to me. Happy for you to squash on merge.

[Sreini]

Re-verified the PHP 5.4 / Windows exclusion after the duplicate-run fix.

Worth checking, because that cell was diagnosed before the race was found — so the original evidence was gathered while the workflow was competing with itself.

Re-enabled it on a throwaway branch with the race fix in place. It still fails, identically:

Validate composer.json and composer.lock   success
Install Dependencies                       failure

  Loading composer repositories with package information
  ##[error]Process completed with exit code 1      ← 0.26s later, no output

composer validate succeeding first proves composer is present and working, so this is not the race's composer: command not found. It is the same TLS crash: PHP 5.4.45 on Windows cannot complete the handshake with packagist and dies rather than erroring.

Independently justified. The exclusion stays, and it is one matrix cell — Windows still covers 5.6, 7.4, 8.0 and 8.5, and PHP 5.4 is still covered on ubuntu and macOS.