Azure-docs: What happens with a message that cannot be delivered to a single subscriber out of many

[SeanFeldman]

For a single subscriber an event that fails all delivery attempts can be dead-lettered.
What about an event that has several subscribers? What the behaviour then? Will an event be dead-lettered if it can't be delivered to one of the subscribers or all subscribers have to fail? The question was originally raise on SO here.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 92671e7c-03e5-591d-7fe2-7c565220242a
• Version Independent ID: 99bdee93-1a4d-d10c-8d90-a58a84bb6187
• Content: Azure Event Grid delivery and retry
• Content Source: articles/event-grid/delivery-and-retry.md
• Service: event-grid
• GitHub Login: @tfitzmac
• Microsoft Alias: tomfitz

[andrewjw1995]

Also in the case of multiple subscribers, I assume that re-delivery attempts are sent to only the subscriber that failed, not to all subscribers, but can this be confirmed in the official documentation?

[Mike-Ubezzi-MSFT]

@SeanFeldman
Thank you for the detailed feedback. We are actively investigating and will get back to you soon.

[banisadr]

Hi @SeanFeldman, deadlettering in Event Grid is configured on each event subscription so the behavior is that the failed event subscription would dead letter the event regardless of what has happened with the other parallel event subscriptions.

This of course implies two interesting questions - how do I know which subscription failed, and if multiple failed, how do I manage the multiple copies of the deadlettered event? Because you can set a specific container as the dead letter destination for each event subscription, the best way to mange either of these scenarios is to have a seperate container per event subscription as a dead letter destination.

[banisadr]

@andrewjw1995 that is correct, in the case of multiple subscribers, thre re-delivery attempts are only sent to the subscriber that failed. We will clarify this in the documentation.

[SeanFeldman]

First, thank you @banisadr.
Second, for the DLQ-ed messages, do you think it would be possible to have those blobs stamped with the failing subscriber info (using blob metadata)? I can see customers asking for a single container, but still be able to identify what subscriber did fail.

[romankiss]

Hi Sean,

The _event topic_, _subscription name_ and _datetime_ are parts of the blob pathname, see the following example:

 testerTopic6/TESTER--2--CLONE/2019/1/24/6/7e194b9c-76ff-41e9-80a3-f8c6be0d4845.json

also, the dead-lettering event message contains this information in the subject property, see an example:

  "subject": "/blobServices/default/containers/test/blobs/testerTopic6/TESTER--2--CLONE/2019/1/24/6/7e194b9c-76ff-41e9-80a3-f8c6be0d4845.json",

Note, that this is a very useful for filtering purposes, when we can subscribe on the storage account and handle a specific dead-lettering for topic and/or subscription.

Having this info in the blob pathname allows to use also a BlobTrigger function for a specific container, topic and subscription.

Thanks
Roman

[mike-urnun-msft]

Hi @SeanFeldman Just checking to see if you had any further questions regarding this matter. Otherwise, we'll proceed to close this issue. Thanks!

[SeanFeldman]

@mike-urnun-msft I'm good. If there's an open PR to update doco you could link this issue to, it would be ok to close this one. Thanks.

[mike-urnun-msft]

We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.