Audit retries and timeouts on develop #276

Activity

1. minhqdao

   added

   v2About the work-in-progress composite action -> TypeScript rewriteAbout the work-in-progress composite action -> TypeScript rewrite

   on Sep 29, 2026
2. djkees commented on Sep 29, 2026

   

   djkees

   on Sep 29, 2026

   More actions

   I spent about five days on this a couple weeks ago; I am collating all of my results and will post shortly :)

   👍React with 👍1Reacted by Minh Dao
3. minhqdao

   changed the title [-]Audit retries and timeouts across setup steps[/-] [+]Audit retries and timeouts on `develop`[/+] on Sep 29, 2026
4. djkees commented on Sep 29, 2026

   

   djkees

   on Sep 29, 2026

   More actions

   Mapped every retry/backoff/timeout on develop — both what GitHub enforces from outside (step- and job-level timeout-minutes) and what the installer code retries on its own inside. Max delay is whichever of those is smaller, since that's the one that actually happens first:

   Compiler	Step-level cap	Job-level cap	Internal retry math (update+install)	Max delay
   gfortran	30m	—	~60m — exceeds cap 2×	30m
   ifort	45m	—	~60m — exceeds cap	45m
   ifx	45m	60m	~90m — exceeds cap 2×	45m
   nvfortran	45m	—	~40m — fits	~40m
   flang (Debian)	none	—	~70m, fully bounded	~70m
   flang (win32/darwin), armflang, aocc, lfortran	none	—	n/a — no cap anywhere in the chain	GH default: 360m

   That last row is the real gap: no step timeout, and nothing internal bounds it either, so a hang runs until GitHub's 6h default finally kills it. That's the one worth fixing, and it doesn't touch anything currently working.

   gfortran/ifort/ifx have the opposite problem: their internal retries are configured to run longer than the timer that kills them anyway, so the extra attempts never get a real chance to complete. Trimming attempts or per-attempt timeout to fit inside the existing cap is close to free, since that excess isn't reliably happening today regardless.

   ifort's and ifx's own outer caps, though, can't safely drop much below 45m — their real ceiling is #272's devenv slowness on windows-2022 (~37m, deterministic, unrelated to retries), not tail risk. nvfortran's cap was already right-sized once (3367da2, raised 30m→45m after real failures hit the old wall), and the data since — zero failures — confirms it was the right call.