Closed danilofuchs closed 2 months ago
The issue with Promise.allSettled and Promise.all is that it has no concurrency control. v9 and below had support for this via the p-map package and used the teamConcurrency
option. However this produced too much complexity for all use cases, since some jobs within a batch may take longer than others, reducing the overall throughput over time.
is that it has no concurrency control
What do you mean by concurrency control in the context of Promise.allSettled
? Not sure I understood the requirement
How many promises run in parallel
We've run into a similar issue, since we have a production system that needs to be upgraded to v10, and it seems it is no longer possible to partially fail a batch of jobs; if one fails all the batch gets failed, which is problematic since it degrades performance. Is there a way to handle these cases by allowing success of non-erroneous jobs?
In addition, we saw in the source code that you either succeed all jobs or none. The greatest danger here is that if one job from the batch fails, all other jobs will also fail. In that case even the successful jobs will be retried, which means that if a job is not idempotent bigger problems will arise.
@timgit tagging you, because I am not sure if notifications reaches you in a closed issue
I'm implementing batch support in my application, and I would like to fail only 1 job of the batch, using
Promise.allSettled
:I could use
fetch
,complete
,fail
myself, but then I loose all theWorker
functionality and have to manage polling myselfWould be nice if
work
had an API for that, for example:work
would only poll again if all jobs have been completed or failed