Live data from Hacker News

setBigTimeout

evanhahn.com

61–70 of 129 posts

Re: setBigTimeout

#61
This 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 speaking from experience)

Re: setBigTimeout

#62

This 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

#63
post #24

> 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…

When implementing a tiny timing library in JS a few years back I found that most engines indeed seem to cast the value to an integer (effectively flooring it), so in order to get consistent behaviour in all environments I resorted to always calling Math.ceil on the timeout value first [1], thus making it so that the callbacks always fire after at least the given timeout has passed (same as with regular setTimeout, which also cannot guarantee that the engine can run the callback at exactly the given timeout due to scheduling). Also used a very similar timeout chaining technique as described here, it works well!

[1]: https://github.com/DvdGiessen/virtual-clock/blob/master/src/...

Re: setBigTimeout

#64
This 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

#65
post #38
post #10

The 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…

It's return your differs between node and in a browser. If you want to type a variable to hold the return value in typescript and share that across node (eg jest tests where you might include @types/node) and the browser you need ReturnType, otherwise the code won't typecheck in all cases. Similar with setInterval.

Re: setBigTimeout

#66

This 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.

Right on. Pretty quickly that's the better solution

Re: setBigTimeout

#67
post #10

The 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…

One could imagine an app that doubles the wait between each failed authentication attempt could exploit this by doggedly trying until the rate limiter breaks. Maybe not the most practical attack, but it is a way this behavior could bite you.

Re: setBigTimeout

#68
post #64

This 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

Re: setBigTimeout

#69
post #25

Earlier 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".

This is not a sourcehut problem, it is a github problem. "Tree" is semantically correct.

Re: setBigTimeout

#70
post #68
post #64

This 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

I don't see how this pricing (or product in general) is any better than cloudflare workers.

To be clear, I am not trying to be mean, I'm just curious to hear why I would pick this over cf.

Post reply on HN