setBigTimeout
61–70 of 129 posts
Re: setBigTimeout
#62This type of thing is actually practical. Google Cloud Tasks have a max schedule date of 30 days in the future so the typical workaround is to chain tasks. As other commenters have suggested you can also set a cron check. This has more persistent implications on your database, but chaining tasks can fail in other ways, or explode if there are retries and a failed request does trigger a reschedule (I hate to say I’m s…
Re: setBigTimeout
#63> In most JavaScript runtimes, this duration is represented as a 32-bit signed integer I thought all numbers in JavaScript were basically some variation of double precision floating points, if so, why is setTimeout limited to a smaller 32bit signed integer? If this is true, then if I pass something like "0.5", does it round the number when casting it to an integer? Or does it execute the callback after half a millise…
[1]: https://github.com/DvdGiessen/virtual-clock/blob/master/src/...
Re: setBigTimeout
#64Re: setBigTimeout
#65The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…
In nodejs you at least get a warning along with the problematic behavior: Welcome to Node.js v22.7.0. Type ".help" for more information. > setTimeout(() => console.log('reached'), 3.456e9) Timeout { } > (node:64799) TimeoutOverflowWarning: 3456000000 does not fit into a 32-bit signed integer. Timeout duration was set to 1. (Use `node --trace-warnings ...` to show where the warning was created) reached I'm surprised t…
Re: setBigTimeout
#66This type of thing is actually practical. Google Cloud Tasks have a max schedule date of 30 days in the future so the typical workaround is to chain tasks. As other commenters have suggested you can also set a cron check. This has more persistent implications on your database, but chaining tasks can fail in other ways, or explode if there are retries and a failed request does trigger a reschedule (I hate to say I’m s…
True. Though if you have a need to trigger something after that much time, you might recognize the need to track that scheduled event more carefully and want a scheduler. Then you’ve just got a loop checking the clock and your scheduled tasks.
Re: setBigTimeout
#67The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected: const attackerControlled = ...; if (attackerControlled { console.log("Surely at least 1min has passed!"); }, attackerControlled); The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better so…
Re: setBigTimeout
#68This is great for the folks running serverless compute! You get to start a process and let it hang until your credit card is maxed out. /s
Re: setBigTimeout
#69Earlier quoted context omitted.
I agree it’s not the prettiest, but I had no trouble clicking on “tree” to get to the folder and then “mod.ts” to see the code.
One has still to know that "tree" stands for "source code".
Re: setBigTimeout
#70This is great for the folks running serverless compute! You get to start a process and let it hang until your credit card is maxed out. /s
That was before DBOS -- the serverless platform that bills you only for CPU time, not wall clock time ;) see https://www.dbos.dev/blog/aws-lambda-hidden-wait-costs
To be clear, I am not trying to be mean, I'm just curious to hear why I would pick this over cf.