[regularfry]

> React gets blamed for this because the error handling is bad and the UX is confusing

Yes, it does.

> React is getting a bad rap because it’s visible when the issue is clearly their backend.

Two things can be bad! Except that in this case one of them is unnecessarily bad, because nobody forced them to use a front end system which defaults to terrible failure handling.

[pc86]

It's also not tautological that React apps have bad error handling. You can do proper error handling and retry logic in React, and I can't for the life of me understand why GitHub engineers making several hundred thousand a year in cash and at least that much in stock simply... don't?

It's no wonder my jobs feed is flooded with senior engineering positions at GitHub (one wonders if they're growing, or jettisoning dead weight) but I can't imagine it's a good look for the resume to put GitHub on it at this point.

[mcepl]

These are the super-engineers who created https://youtu.be/E3_95BZYIVs

[rmunn]

Oh man, I'd actually forgotten about that!

What's hilarious about that script is that the solution is so simple: use a less-than comparison instead of an equals. That's really, really all it would have taken to fix the issue. And yet https://github.com/actions/runner/pull/3157 was opened on 2024-02-17 and was merged on 2025-08-21, a full 18 months (plus a few days) later! It took literally 18 months for them to merge a bugfix that is trivially obvious to see is correct.

Yeah, the problems at GitHub ran (and still run) deep.

P.S. Yes, there are busy-wait issues in that code, which should have been addressed by bringing back the check for the `sleep` command and using it if available, falling back on the CPU-burning busy-wait only if `sleep` was unavailable. But the most revealing thing is the 18 months to merge a trivial-to-verify PR. That, more than the bad busy-wait loop, is the fundamental indicator of brokenness at GitHub under Microsoft's ownership.