Events / Callbacks

[Mortalife]

Do you think it would be possible to expose an event emitter on the engine which fires events when jobs are completed/failed?

I'd like to be able to do things in my application in response to jobs completing without having to poll for changes.

If such a system were implemented, then an additional Job convenience method of "event" would also be helpful for allowing me to emit an event manually.

The immediate and most obvious downfall of a system like this would be whom receives the event, in a distributed system you may pick up an job that was enqueued on a different node. Would you expect the enqueuing node to receive the event, or the node running the job?

For my use case it's absolutely fine that that stays a problem for the user in user land, and that the node that processes the job receives the event.

Are there any glaring issues which make this non-viable?

[GiovaniGuizzo]

Maybe. If we were to do that, the processing node would be the only one receiving the event.

[Mortalife]

Yeah, that approach would mean there wouldn't be a huge amount of work, you'd hook into the IPC events. To do anything else, particularly if you didn't want to bring in external dependencies and be db agnostic as you mostly are, would require an outbox or event log/consumer stream tables or something.

I currently solve this problem by firing back into my application on api endpoint for events, but I'd rather not go to the network for the event sending, if it can be done in process.