• 516052 (unregistered)

    What exactly is the purpose of a wait if you can't rely on it being correct in at least one direction? At that point it's basically just yield.

  • (nodebb)

    If you ask me to pick a language to develop something timing-sensitive you'd have to beat me repeatedly with a stick before I agree to use TS/JS.

  • 516052 (unregistered) in reply to AGlezB

    If you ask me to pick a language to develop something ~~timing-sensitive~~ you'd have to beat me repeatedly with a stick before I agree to use TS/JS.

    Fixed that for you.

  • 516052 (unregistered)

    Also, apparently ~~ does not work in quote tags. Great. I miss BBCode.

  • ttlanhil (unregistered) in reply to AGlezB

    To be fair... The code itself may well be sane, it's stuff in tests. I've had times where I want to load data into the database and then run code that queries it in a test harness (yeah, you can stub out most of the DB side of tests - tradeoffs...), and if you're looking at some sort of eventually-consistent DB then you may need to wait for a bit before querying. You rarely want to do too much of that in unit tests, but an integration test or two (particularly during deploy in CI/CD) to sanity test things can catch weird bugs

    Or you could be testing network timeouts or watchdog code - but that's hopefully a library rather than your general code

  • Rob (unregistered)

    Terrible that this is the best solution.

    No it's not. A better solution would be to not use a 1 ms timeout but use the remaining difference to the target. You start with the desired timeout. If the timeout is triggered after that time, great, you only have one timeout call instead of possibly hundreds. If it gets triggered X ms too soon, you use a timeout of X. Continue until X <= 0.

  • Unknown Solider (unregistered) in reply to Rob

    I'd probably use mocked timers and advance the clock instead, if that's an option. Otherwise I'd poll for the expected state with a timeout instead of sleeping a fixed duration. Most testing frameworks support this, and it also avoids waiting for long timeouts in CI. The original approach feels like we're testing the nodejs internals, but we haven't seen the actual test.

  • Hmmmm (unregistered)

    Makes one wonder what data structure is being used to hold their async operations.

  • (nodebb)

    Unfortunately the nature of the beast is that tests which rely on timing are inherently flake-prone, especially when they have to run on a loaded CI/CD box. It may all run fine on beefy developer machines, but they will flake when run on a CI/CD box which might also be running many other jobs and/or is underprovisioned for the load to which it is subjected.

    Addendum 2026-07-16 17:06: To be perfectly clear: the beefiness refers to the machine, not the developer.

  • (nodebb) in reply to Unknown Solider

    Yeah, Jest has an option to lie, cheat, and steal your way through time, by ignoring the wall clock and only advancing "time" when you instruct it to.

    I just had to use that recently, in a codebase that had a linting rule banning Jest's mock timers, because someone wrote a test that said "I'm expecting a thing at 250ms. So, let's wait 249ms, assert it isn't there, then wait 1ms and assert it is." The funny thing is that test rarely failed... until my laptop was overloaded.

  • Anon E. Mouse (unregistered)

    I once spent 40 hours debugging a race condition.

    This was an important (but cheap - that folds into the tale) and valuable maintenance client. I think the salesperson had gotten a few drops of blood out of the stone and, after that miracle, wanted to provide premium support at dirt cheap prices so at the next maintenance renewal they would re-up and the salesdroid would be feted as the hero who charmed $1,500 out of Mr. & Mrs. Too Cheap to Buy Support.

    The only thing anybody could come up with from the error message was that faint whiff of a race condition.

    After two members of my team failed to reproduce it, it got bounced to me, the manager. I think the expectation was for me to close it as "not reproducible". None of our other 40 clients had the problem either.

    Thinking about it, the one unique thing about the Cheaps was that they used hardware that barely met our software's requirements. It wasn't 286s in a 486 world, but their machines weren't much better. That was a crack of light illuminating a room and showing the sparkles of dust motes. Turns out I had the slowest machine in the shop (my manager's laptop).

    Thinking about it, I wondered if my machine was slow enough to expose the race. I had bought my team equipment that was too good, too fast...

    But every time I tried instrumenting the code, the problem went away. Stepping through using the debugger -- not reproducible.

    Finally, late Friday afternoon, I gave up and added ONE line to the code base

    if (1 = 1) then ;

    knowing that PowerBuilder was too stupid to optimize it away, but it would compile into a conditional instruction which would play havoc with the processor's "early generation and fairly stupid" (there should be a TLA for that) branch prediction logic.

    At the next team meeting, I casually mentioned that I had resolved the bug (without offering ANY details) and -- even though a manager -- added a little more burnished tech gold to my slightly tarnished tech god crown.

Leave a comment on “Wait Longer”

Log In or post as a guest

Replying to comment #702021:

Log Out

« Return to Article