Pub/Sub example - message delivery failures confusion

Developers
1

Hey,
I have just tried the Pub/sub example out (https://github.com/dfinity/examples/tree/master/motoko/pub-sub). The docs say “PubSub is an especially valuable pattern on the Internet Computer as its primary drawback, message delivery failures, does not apply.”

Why does message delivery failures not apply here to? Docs here https://sdk.dfinity.org/docs/interface-spec/index.html#http-call-overview say that a message can be rejected by system or before the “received” state.

So one still need to check if the call in Pub/Sub scenario was rejected or not?
And can the message in inter-canister communication be dropped before the “received” state (https://sdk.dfinity.org/docs/interface-spec/index.html#http-call-overview) or does it only apply to user-canister communication?
Can someone elaborate more on the message delivery failures, does not apply statement from the Pub/Sub example docs and if there are different message delivery guaranties between canister-canister and user-canister communication?

Thanks

2 Likes
2

I think the short answer is that the statement in the example is probably misguided (i.e. wrong). Inter-canister messages, even oneway messages that don’t return any response, can, as far as I know, still fail for many reasons (e.g. if the canister for a subscriber was deleted). @nomeata can you confirm?

(FWIW, the part of the spec you mention The Internet Computer Interface Specification :: Internet Computer is not entirely appropriate since it’s talking about the http interface by which external agents communicate with the IC to sent “ingress” messages, not the internal, inter-canister communication that the pub-sub example is demonstrating)

2 Likes
3

Inter-canister messages cannot fail silently; you eventually either get a reply or a reject. A reject could be due to problems like “destination canister deleted” or “destination out of cycles” or messaging-related issues like “queue full”.

4 Likes