Understanding Poison Message Handling in Azure Message Queue and using it in Logic Apps

Question

I'm trying to make a workflow using Azure Logic Apps where several Azure Functions are connected. I'm using a blob trigger and im sending its content to the first function, then, that function sends a http req to the next one and so on. However i would like to make sure that the first function processes it correctly. So i figured i could use Message Queue, as it supports Poison Message Handling.

Now, the blob trigger puts a new message in a queue, which is then proccessed by the first function. I've seen many articles about how i can set retry policies (how many times a message should be proccessed, and intervals between retries), however i can't quite find information about how i can use the Poison Message Handling. So my question is:

How are those poison messages handled after exceeding the retry count,

Are they just staying in that queue, but are marked as poison?

Are they put in some other queue, that contains only the poison ones?

How can i take advantage of even finding them? Is it only possible to manage them by hand, or can i set up some kind of trigger that fires when a poison message occurs?

I am also wondering if my approach is correct. Is it fine to connect Azure Functions directly to each other in Logic Apps, or should each has its own Message Queue? Do i even need the message queue to handle Poison Message or is there a good way to do it in Logic Apps directly (I know that it's possible to set retry settings, but i haven't seen anything about automatic poison message handing)

Answer 1

Poison messages are explained in Trigger - poison messages:

If all five attempts fail, the functions runtime adds a message to a queue named <originalqueuename>-poison. You can write a function to process messages from the poison queue by logging them or sending a notification that manual attention is needed.

To add, the message is removed from the original queue.

So, poison queue is just another queue and you can process messages in that queue as you wish (e.g. with another Azure Function).

Whether your exact approach is valid or not depends on details of your requirements, and I think it's out of scope for this question. It might be a viable approach.