⚡ Add manageable acknowledge for services #2646
Conversation
|
Hi, This is an initial idea for adding manageable acknowledge for Trigger nodes such as MQTT, RabbitMQ, Kafka and etc. There is room for improvement since it is using Maybe this should have its own I would love to hear what could be improved. |
Add the option to acknowledge or not acknowledge messages coming from some trigger services. The current implementation reuses `sendResponse` logic from node `RespondToWebhook`.
m2scared
force-pushed
the
feature/trigger_ack
branch
from
bfe3204
to
bbe80ee
Compare
ivov
added
node/improvement
|
Hi @Joffcom, If you have time, I would love to hear your thoughts on this one. Thanks. |
|
Hi @nivb06, What do you think about this one? |
|
Hey @m2scared, I like the idea, I am not sure if "Respond to trigger" is too generic though as it wouldn't do anything for any of the other trigger nodes at the moment (apart from webhooks). Would it maybe be better as an option in the RabbitMQ node for now if possible? Do you also have an example of when you may use this? |
Hi @Joffcom,
Understood. I used this name because it can be reused in other "queue" nodes that support NACK such as Kafka.
I agree. My use case is: the event should be acknowledge only if the workflow succeeds. Currently this is not possible with n8n as far as I know. Is there any other way to archive this? I will change the patch only for RabbitMQ. |
|
No other way I can think of to handle it at the moment, Makes sense that you would only want to ack a success as well. In the past when implementing a logging system for file transfers with an MQ broker (Websphere I think it was) we would just post a sucess message to a queue / topic and include the original MQ ID as a header but I guess something like that would depend on how the interacting systems are working together. |
I am not quite sure if I understood. Do you have examples? Code? It seems possible to do since there is a similar behavior with 'webhook' and 'respond to webhool'. My current implementation uses |
|
Sadly nothing I can share for the old MQ project as it was done using other systems for an old customer, If I get a chance I will see what I can remember but chances are as you are already doing something with MQ it may not be that helpful. It all depends on what your MQ process currently is, So we were getting an MQ message with transfer info in it and would then connect to a server to download or upload a file then anything that happened would be logged to a queue and the MQ ID was passed along the MQ messages. They then had this neat web based system which would show them everything when then entered the ID. |
|
Hello @m2scared , thank you for your contribution, as for now it seems that RespondToTrigger node is redundant and too tied to RabbitMQTrigger node, as this node only hold boolean value it probably can be replaced with an option in RabbitMQ trigger node. Would be great if you can share workflow with setup where you are using this node, as it will clarify use case and gives possibility of alternative solution without necessity to add additional node. RabbitMQTrigger uses amqplib, here is documentation that can be useful. |
|
Hi @m2scared, I will be closing this as of @michael-radency's comments. |
Add the option to acknowledge or not acknowledge messages coming from
some trigger services.
The current implementation reuses
sendResponselogic from nodeRespondToWebhook.