Event acknowledgement

[icebob]

• Start Date: 2019-09-04
• Target Version: (0.14 / 0.15)
• Reference Issues: (fill in existing related issues, if any)
• Implementation PR: (leave this empty)

Summary

Implement acknowledgement for events.

Basic example

In caller side

await this.broker.emit("user.created", { user }, { ack: true });

In event handler side

// activation.service.js
module.exports = {
    name: "activation",

    events: {
        async "user.created"(ctx) {
            try {
            await this.activateUser(ctx.params.user);
            
            // Acknowledges the received event.
            ctx.ack();
            } catch(err) {
                // Negative acknowledges the received event.
                ctx.nack();
            }
        }
    }
};

Motivation

TODO

Detailed design

TODO

Drawbacks

TODO

Alternatives

TODO

Adoption strategy

TODO

Unresolved questions

• What happens with broadcast messages. Sending to all services?
• What happens if mixins register the same event listener, so the service has multiple handlers for the same event?
• How the caller side can check the acknowledgement result that it was successful or not?
• What happens, if one listener was successful and other was failed?

[tobydeh]

+1 for this feature - I think its the only real feature that Moleculer lacks.

[juanchristensen]

What happens with broadcast messages. Sending to all services?

I think it's rare for a broadcast events to require processing guarantees.
So unless there is a strong case to include that capability, I wouldn't add it to the RFC.

[juanchristensen]

What happens if mixins register the same event listener, so the service has multiple handlers for the same event?

If the service has multiple handlers for the same event, I would consider those different consumers altogether.
So, you would have different consumer IDs for each.

[juanchristensen]

I like the approach from NATS Streaming, both the producer and the consumer are responsible of setting their required guarantees.
The producer might need to ensure reliable delivery, but cannot enforce reliable processing (since producers don't know which consumers are listening to an event).
On the other hand, the consumer is the one that knows how important that event is from its own perspective, and what guarantees are necessary.

I would add the { ack: true } on both the producer and event handler (as optional params).

[icebob]

I would add the { ack: true } on both the producer and event handler (as optional params).

Good idea, thanks!

[juanchristensen]

Regarding the last two questions, based on my previous answer I think both can be resolved as well.

How the caller side can check the acknowledgement result that it was successful or not?

The caller on any event based system never needs processing guarantees, just delivery guarantees (optionally).
And in many cases, it's not even interested in the delivery to the end consumer (since it's not aware of how many consumers are actually available), but instead the delivery to the message transport / broker.

What happens, if one listener was successful and other was failed?

Success from the consumer perspective is individual and independent per consumer.
So, this situation is dependent on whether the individual consumers had { ack: true } in their event handlers or not.

[sskhokhar]

Any update on this? Since i need reliability to use Kafka with acknowledgement for sensitive never-loose data.

[benjick]

@sskhokhar have you seen this? https://github.com/moleculerjs/moleculer-channels