Logic App Standard Build-in Get Deferred (Preview) action 'Unauthorized access'

[JeffreySchmitz-Motion10]

Describe the Bug

We have multiple logic app standard statefull workflows that follow the pattern of listening to a servicebus topic subscription, defer the message, run business logic, get deferred message and complete/deadletter the message. This works fine, but sometimes out of nowhere the In-App/Build In "Get Deferred Message for Topic" action just starts throwing the following error:

The service provider action failed with error code 'ServiceOperationFailed' and error message 'Unauthorized access. 'Listen' claim(s) are required to perform this operation. Resource: 'sb://xxxx.servicebus.windows.net/orders/subscriptions/xxxxx/$management'. 
TrackingId:459dde8d-b2cc-46e2-a73f-d47e3fb724dd_G62, SystemTracker:NoSystemTracker, Timestamp:2024-07-29T06:49:36\r\nFor troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.'.

Application Insights exception shows the following:

System.UnauthorizedAccessException: Unauthorized access. 'Listen' claim(s) are required to perform this operation. Resource: 'sb://xxx.servicebus.windows.net/orders/subscriptions/xxx/$management'. TrackingId:9fe5782c-8697-4f52-8117-d9ac6778cc38_G24, SystemTracker:NoSystemTracker, Timestamp:2024-07-29T06:42:45
For troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.ReceiveDeferredMessagesAsyncInternal(Int64[] sequenceNumbers, TimeSpan timeout)
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.ReceiveDeferredMessagesAsyncInternal(Int64[] sequenceNumbers, TimeSpan timeout)
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.<>c.<<ReceiveDeferredMessagesAsync>b__72_0>d.MoveNext()
--- End of stack trace from previous location ---
   at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.RunOperation[T1,TResult](Func`4 operation, T1 t1, TransportConnectionScope scope, CancellationToken cancellationToken, Boolean logTimeoutRetriesAsVerbose)
   at Azure.Messaging.ServiceBus.ServiceBusRetryPolicy.RunOperation[T1,TResult](Func`4 operation, T1 t1, TransportConnectionScope scope, CancellationToken cancellationToken, Boolean logTimeoutRetriesAsVerbose)
   at Azure.Messaging.ServiceBus.Amqp.AmqpReceiver.ReceiveDeferredMessagesAsync(Int64[] sequenceNumbers, CancellationToken cancellationToken)
   at Azure.Messaging.ServiceBus.ServiceBusReceiver.ReceiveDeferredMessagesAsync(IEnumerable`1 sequenceNumbers, CancellationToken cancellationToken)

The service bus trigger, the defer message action all keep working, just this action stops working. The system managed identity of the logic app has Receiver & Sender permissions at namespace level of the service bus. The solution we found so far is restarting (of stop/start) the Logic App and everything starts working again for many hour untill suddenly it stops working again.

Plan Type

Standard

Steps to Reproduce the Bug or Issue

1. Create a new Logic App Standard with a Service Bus When messages are available in a topic subscription (peek-lock) trigger
2. Add Defer the message with the In-App Service Bus action
3. Add Get Deferred message with the In-App Service Bus action
4. Let it process messages for a day or more

Workflow JSON

No response

Screenshots or Videos

Additional context

No response

[Berend-Kalberg]

I have encountered the same issue. It would be great if Microsoft could take a look at this issue.

[rvvincelli]

Hi! Your issue might be totally unrelated, it's just that audience and managed identity make me think of this. In our case, using a vanilla managed identity to access a storage account from an in-app connector is just not possible.

This one looks related too.

[JeffreySchmitz-Motion10]

@rvvincelli I just replied to you issue. We use blob connection and it works just fine. Also the issue is that our setup works, but at some point just stops working. After a restart of the logic app, it all starts working again for a while...

[rvvincelli]

Hi @JeffreySchmitz-Motion10 , thanks for the follow-up, indeed mine was just a hint and your issue might be unrelated, let's see what the team says.

[github-actions[bot]]

This issue is stale because it has been open for 45 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.