▲ | weego a day ago | |
This looks really interesting, congrats! One thing I did notice though from looking through the examples is this: Uncaught errors automatically cause retries of tasks using your settings. Plus there are helpers for granular retrying inside your tasks. This feels like one of those gotchas that is absolutely prone to benign refactoring causing huge screwups, or at least someone will find they pinged a pay for service 50x by accident without realising. ergonomics like your helper of await retry.onThrow feel like a developer friendly default "safe" approach rather than just an optional helper, though granted it's not as magic feeling when you're trying convert eyeballs into users. | ||
▲ | matt-aitken a day ago | parent [-] | |
Yep you do need to be careful with uncaught errors. When you setup your project you choose the default number of retries and back-off settings. Generally people don't go as high as 50 and setup alerts when runs fail. Then you can use the bulk replaying feature when things do wrong, or if services you rely on have long outages. I think on balance it is the correct behaviour. |