Guaranteed message delivery or confirmation of receipt

Hi, I need advice on the question I’m interested in. To what extent does this product provide guaranteed message delivery? I will give an example, if some subscriber was unavailable and did not receive a message and after some time became available on the network, will he receive his message?

Hey @vdrobyshev!

Welcome to the community :tada:

Can you please elaborate on what do you mean by “Message”? Are you talking about chat platforms or messages passed via Pub-Subs or something else?

I am interested in all the messages about which you wrote including. And I wonder if the final server will be unavailable when sending to it, what will happen in the future, will it fail, or will it wait until the server becomes available?

It depends on what kind of messages you are sending, the messaging platform, and how they handle the situation. n8n will send a message to the requested server. Based on the response from the server (if any) n8n will display you the status. If there is no response and n8n doesn’t receive any information back from the server, it will have an error status. But as mentioned earlier, it really depends on the type of message and the platform. Without the specifics, it is difficult to give an accurate answer.

I’ll ask you another question. Is there an internal queue there? how close is it to data buses - ESB

There is no queue. If a node fails will by default the execution fail. You can optionally set on a node that it should retry a few times and wait in between tries. But that is in the seconds not minutes or hours.

Depending on how you have n8n setup or you have configured the workflow (via its settings) will that failed execution then be saved and you can then manually retry it again at a later point.

not to speak out of turn but n8n is currently an ETL / point to point solution that operates in general out of the box as a request response synchronously… a generalisation…but it certainly is not an ESB/SEDA under the covers. BUT that is not a criticism it is a description, there is nothing stopping you adding database/queue/event stream to your flows as the nodes exist…and if you want to store errors, retries, problems in your middleware then get queuing, personally if I can get away with it I like to return the error handling back to the calling tier when ever possible for their retry mechanisms…trying to keep middleware as simple as possible

Sometimes the vendor does provide a cloud option which n8n does and within the cloud option the vendor hosts queue instances for you to use which I dont know whether n8n offers today.

Thanks a lot @georgejeffcock!

Currently, not even our cloud open works differently as the cloud offering is really to 100% the same as the version that people can self-host.

Generally, do we have planned to improve how n8n can handle the situation if for example, a service is down. Sadly do not have an ETA for that right now.