Jens-G opened a new pull request, #3859:
URL: https://github.com/apache/thrift/pull/3859

   The MINGW job brings MSYS2 up to date with pacman before it builds anything. 
MSYS2 on the AppVeyor image is old, so the second `pacman -Syu` is a full 
system upgrade, currently 193 packages and 414 MiB, and **a single failed 
download makes pacman abandon the whole transaction**. The job then goes red 
without having compiled anything.
   
   The file that fails is always a signature. pacman tries a package on each 
mirror in its list in turn, but it requests the package's `.sig` only from the 
mirror that served the package, with no other server to fall back on 
(`lib/libalpm/dload.c` in pacman 6.1.0). One reset connection or a ten-second 
stall on that mirror therefore ends the transaction:
   
   ```
   error: failed retrieving file 'libnettle-4.0-1-x86_64.pkg.tar.zst.sig' from 
us.mirrors.cicku.me : Recv failure: Connection reset by peer
   error: failed retrieving file 
'mingw-w64-i686-gcc-16.2.0-3-any.pkg.tar.zst.sig' from ftp2.osuosl.org : 
Operation too slow. Less than 1 bytes/sec transferred the last 10 seconds
   ```
   
   This took down the MINGW job in builds 54721340, 54721515, 54729139 and 
54733215, four of the last 40 builds; in the latter two, all five MSVC jobs 
passed. Build 54712971 failed the same way on a database signature.
   
   ### The change
   
   Each of the three pacman calls in `MINGW-appveyor-full.bat` now goes through 
the new `pacman-retry.bat`, which makes up to three attempts 30 seconds apart. 
Every attempt starts again at the first mirrorlist entry, `mirror.msys2.org`, 
which redirects each request to one of many mirrors, and pacman skips each 
package whose file and signature are already in its cache, so a retry fetches 
little beyond what failed. A signature that fails in all three attempts still 
fails the job.
   
   The pauses fit into the time budget: green MINGW jobs took 39 to 74 minutes 
(median 48) over the last two weeks, against AppVeyor's 90-minute job limit for 
this account.
   
   Two constraints shaped the helper:
   
   - **The retry is in cmd, not in a bash loop.** When the MSYS2 core packages 
are outdated, as they are on this image, the first `pacman -Syu` updates them 
and then closes every other MSYS2 process with `taskkill`. bash execs a lone 
command instead of forking it (checked with bash 5.3 on Linux, also as a login 
shell with a profile), which is why no bash process is left to close today. A 
bash loop would keep its own process running, and `taskkill` would end it along 
with the loop. Each attempt therefore keeps pacman as the only command in the 
`bash -lc` string.
   - **No `GOTO` loop.** The `.bat` files reach AppVeyor with LF line endings 
(GitHub's archive of master has no CR in them), and cmd.exe does not find 
labels reliably in such files, so the three attempts are written out one after 
another.
   
   `MSYS-appveyor-full.bat` has the same three pacman calls, but it exits with 
"Unsupported PROFILE" before reaching them and `appveyor.yml` has no job for 
it, so it is left unchanged.
   
   ### Tests
   
   There is no unit test for a download step. On AppVeyor, a run without a 
failed download exercises only the first attempt of each call; that still 
covers the arguments passed through `CALL` and the core-upgrade `taskkill` on 
the real image, but not the retry itself.
   
   The retry paths were exercised beforehand by running the real 
`MINGW-appveyor-full.bat` under Wine 10 with a stub `bash.exe` that fails 
chosen pacman calls:
   
   | Scenario | Unchanged script | With this change |
   |---|---|---|
   | no failures | 3 pacman calls, build, tests | same; pacman arguments 
identical |
   | second call fails once | stops, no build | retried, build and tests run |
   | every call fails once | – | each retried once, build and tests run |
   | one call fails twice | – | third attempt succeeds, build and tests run |
   | one call fails three times | – | stops before the next step, exit code of 
pacman passed on |
   
   Wine 10 drops the errorlevel on a bare `EXIT /B`, which the script uses on 
every line and which real cmd keeps (the AppVeyor logs show the exit code 
arriving). The exit codes in the last row were therefore checked on a copy with 
those `EXIT /B` made explicit.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to