You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to preempt the worker backing off when there is nothing to claim, we're proposing that the WorkerChannel subscribes to events emitted when a run is created and then send a work-available event to the worker.
We may need to leverage the worker version API, as we don't want to send a message to a version of the worker that might error out when receiving an unknown message.
Implementation notes
We need to be respectful of the inbox of the worker channel, when runs are created it will be a lot of messages, often dozens or hundreds in a single minute. It’s unlikely there is enough worker capacity to deal with all of those at once, we should subscribe in a different process and debounce the events calling the parent (worker channel process) at most every 500ms, with a leading call (call immediately if there is no timer, and after 500ms if there are subsequent events).
Release notes
User acceptance criteria
The text was updated successfully, but these errors were encountered:
See: OpenFn/kit#869
Details
In order to preempt the worker backing off when there is nothing to claim, we're proposing that the WorkerChannel subscribes to events emitted when a run is created and then send a
work-available
event to the worker.We may need to leverage the worker version API, as we don't want to send a message to a version of the worker that might error out when receiving an unknown message.
Implementation notes
We need to be respectful of the inbox of the worker channel, when runs are created it will be a lot of messages, often dozens or hundreds in a single minute. It’s unlikely there is enough worker capacity to deal with all of those at once, we should subscribe in a different process and debounce the events calling the parent (worker channel process) at most every 500ms, with a leading call (call immediately if there is no timer, and after 500ms if there are subsequent events).
Release notes
User acceptance criteria
The text was updated successfully, but these errors were encountered: