Why Logic Apps run history is showing failure, while the message is processed successfully?

Hi @Karthik K Koneru ,

Thanks for reaching out to Microsoft Q&A.

The run is marked as “Failed” because one of your connector actions (the manual “Dead-letter the message” step) returned a BadRequest, even though Service Bus did end up moving the message into the DLQ. A run is considered Failed as soon as any action returns a non-2xx HTTP response, regardless of whether the backend state ended up the way you wanted.

Why this happens in your workflow:

• Service Bus automatically dead-letters messages once they exceed the max delivery count (the message properties show deadLetterReason = MaxDeliveryCountExceeded).
• Your Logic Apps step then tries to manually dead-letter that same message by lock token. Because the message’s already gone, the Service Bus connector API returns a 400 BadRequest.
• Logic Apps flags that connector call as a failure, so the overall run status is Failed—even though the message did end up in the DLQ.

Steps to resolve it:

1. Add proper error handling around your dead-letter action. Put it into a Scope or a nested workflow with “Configure run after” so that the BadRequest is caught and treated as a success. For example, use an HTTP Response or a “Terminate” action with status = Succeeded.
2. Only call manual dead-letter when you’re sure the lock token is still valid. For example, use a delay or check DeliveryCount before you invoke the dead-letter connector.

Hi @Karthik K Koneru , following up to see if the above provided information is helpful. Please let me know if you have any questions.

Thank you for the detailed explanation — that clarified why the Logic App run is marked Failed even though the message ends up in the DLQ. That part makes sense now.

I have a follow‑up question regarding DLQ reprocessing behavior, specifically for messages that were automatically dead‑lettered by Service Bus with (deadLetterReason = MaxDeliveryCountExceeded)
Messages are dead‑lettered in two ways:
Automatically by Service Bus when max delivery count is exceeded.
Manually by Logic Apps when a downstream API call fails

We have a secondary Logic App workflow that runs once daily to:

Read messages from the DLQ and Re‑enqueue them to the main queue for reprocessing.
Messages that were manually dead‑lettered are consistently picked up by the DLQ reprocessing workflow.However, messages with (deadLetterReason = MaxDeliveryCountExceeded) are sometimes not picked up on the first run of the DLQ reprocessing workflow.If I re‑run the same workflow, those messages are then picked up and processed.
Is there any known or expected behavior where automatically dead‑lettered messages (MaxDeliveryCountExceeded) are not processed on the first run?
I’d appreciate any guidance or best practices. Thanks in advance for the help!

@Karthik K Koneru This isn't a bug in Logic Apps or Service Bus, but a side-effect of how the Service Bus DLQ trigger polls and how “automatic” dead-lettering happens under the covers:

1. Automatic dead-letter (MaxDeliveryCountExceeded) happens entirely in the broker and then the message shows up in the DLQ.
2. The Logic App Service Bus DLQ trigger is a polling trigger (peek-lock style), so there can be a small delay from the time the broker moves the message to DLQ and when that message becomes visible to your trigger.
3. If your daily DLQ-reprocessing runs immediately after a batch of messages auto-dead-letter, some messages might not yet be surfaced when the trigger polls. A quick rerun a few seconds or a minute later will then pick them up once they’ve fully landed in the DLQ.

What you can do to smooth this out:

Introduce a short “warm-up” or delay (for example, 30–60 seconds) in your schedule so the DLQ trigger has time to see all newly dead-lettered messages. Tune your Service Bus trigger settings, you can increase the polling interval, batch size, or prefetch count in the trigger’s settings to grab more messages per poll.

As a best practice, consider using automatic DLQ forwarding (Service Bus redrive) or an Azure Function/Logic App pattern that moves DLQ messages back into your main queue on a continuous basis instead of a once-a-day job.

Lastly, you can always drill into your trigger history and run history to confirm exactly when the trigger fired.

Thank you for the explanation. This helps clarify why the behavior is occurring, especially around the broker-side DLQ move and the polling/peek-lock nature of the Logic Apps trigger.

Our use case, however, is slightly stricter: we rely on a once‑per‑day DLQ reprocessing workflow and need it to deterministically pick all DLQ messages, regardless of deadLetterReason, without requiring manual reruns or tuning based on timing windows.

While introducing delays or increasing polling frequency can reduce the likelihood of misses, they still feel more like mitigations than a guaranteed solution for batch-style DLQ reprocessing.

Would you be open to a quick call to discuss recommended design patterns that ensure full DLQ coverage (especially when mixing automatic and manual dead-lettering)? 

I think a short discussion would help us align on the most robust approach.

Appreciate your insights and guidance. Thanks again.