ServiceBus built-in complete action fails to complete messages on ServiceBus queue

[rob-thijssen]

Describe the Bug

ServiceBus built-in complete action shows inconsistent behaviour when running to complete a message on the ServiceBus queue. Sometimes it successfully completes the message, other times it fails with a bad request result

{
    "statusCode": "BadRequest",
    "body": {
        "code": "ServiceProviderActionFailed",
        "message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'The Service Bus receiver was not found to perform operation 'completeMessage' on message id '5115677d-c322-4c35-b377-524490118728'.'."
    }
}

Plan Type

Standard

Steps to Reproduce the Bug or Issue

1. Setup workflow with built-in ServiceBus trigger "When messages are available in a queue (peek-lock)"
2. Add any action (eg. Compose)
3. Add built-in ServiceBus action "Complete the message action"

Add a new item to the queue the trigger is listening to. When running the workflow, the message with messageId SOMETIMES (50/50 chance) not complete as result of a bad request

  "code": "ServiceProviderActionFailed",
  "message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'The Service Bus receiver was not found to perform operation 'completeMessage' on message id '5115677d-c322-4c35-b377-524490118728'.'.```

After the lock release a new run is triggered. This run the message is might still not be completed successfully, or is successfully completed.

### Workflow JSON

```json
{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
      "Complete_the_message": {
        "type": "ServiceProvider",
        "inputs": {
          "parameters": {
            "messageId": "@item()?['messageId']"
          },
          "serviceProviderConfiguration": {
            "connectionName": "servicebus",
            "operationId": "completeMessage",
            "serviceProviderId": "/serviceProviders/serviceBus"
          }
        },
        "runAfter": {
          "Compose": [
            "SUCCEEDED"
          ]
        }
      },
      "Compose": {
        "type": "Compose",
        "inputs": "@triggerBody()?['contentData']",
        "runAfter": {}
      }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "triggers": {
      "When_messages_are_available_in_a_queue_(peek-lock)": {
        "type": "ServiceProvider",
        "inputs": {
          "parameters": {
            "queueName": "@parameters('myworkflow').queueName"
          },
          "serviceProviderConfiguration": {
            "connectionName": "serviceBus",
            "operationId": "peekLockQueueMessages",
            "serviceProviderId": "/serviceProviders/serviceBus"
          }
        },
        "splitOn": "@triggerOutputs()?['body']"
      }
    }
  },
  "kind": "Stateful"
}

Screenshots or Videos

Additional context

No response

AB#22207018

[bchebrou]

Hello, any updates on this bug ? I'm facing the same issue when using the app-in connector. Is it possible to use it or should we use the shared connecter when using peek-lock mode ?

[Amelsfort]

Same here. I thought it was because the process took too long, but that's not the case. The process finishes in a few seconds, but the error still occurs.

[wsilveiranz]

Hi all, did you check if you got the right configuration setup for peek-lock. At this stage, there is a series of pre-requisites to use the peek-lock functionality - https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/enabling-service-bus-and-sap-built-in-connectors-for-stateful/ba-p/3820381

[bchebrou]

Hello Wagner, thanks for your reply. I was not aware of these pre-requisites. I will try them, for the moment i'm still using the shared connector.

[kevin-henshall-ip]

Hi @wsilveiranz ,

I have attempted to follow all of the instructions provided in the linked article (https://techcommunity.microsoft.com/t5/azure-integration-services-blog/enabling-service-bus-and-sap-built-in-connectors-for-stateful/ba-p/3820381) but am still encountering random errors (albeit with a different error message) when the logic app attempts to complete the messages.

Specifically, the error message I'm receiving is: "The service provider action failed with error code 'BadRequest' and error message 'The lock supplied is invalid. Either the lock expired, or the message has already been removed from the queue. For more information please see https://aka.ms/ServiceBusExceptions". The logic app runs don't appear to be running for longer than the service bus queue's lock duration so I suspect that there is some inter-instance communication not working as expected.

My logic app is integrated into a VNet, I have configured the scale out of the app service plan to be limited to 4 (as shown in the screenshot from the above link) and have configured the 'vnetPrivatePortsCount' property to 2 (which I've confirmed has been applied via the az cli as the portal continues to show a value of null for this property when viewing the resource json).

Is there anything else which is required?

Thanks

Kevin

[github-actions[bot]]

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

[rob-thijssen]

This week I tried to implement the built-in service connector for receiving and completing service bus topic messages. I followed the instructions as already mentioned (https://techcommunity.microsoft.com/t5/azure-integration-services-blog/enabling-service-bus-and-sap-built-in-connectors-for-stateful/ba-p/3820381)

But the connection is not stable. Every n-th request (when pushing lots of messages to servicebus) is failing to complete the message. No error message is visibile in the connector in the workflow run history. But Application Insights is showing some exceptions. The failed run correlates with a 400 bad request exception in Application Insights. Is this a known issue for the LogicApps team? Can someone please advice on extra settings that are required perhaps?

Thanks in advance, Rob

[rob-thijssen]

I am really eager on using the built-in service bus connector for receiving messages using peek-lock, but unfortunately we are not able to as this issue is still open.

Can someone please help me finding a solution so we can use the built-in connector and remove the managed service bus connector??

[Dhana1207]

we are also facing the same kind issue and raised the issue in https://github.com/Azure/logicapps/issues/874 we are awaiting for microsoft response. Please let me know if you get to know about any solution.

[Dhana1207]

@rob-thijssen Are you still facing this issue? in Logicapp std , we were able to resolve the issue by enabling Vnet and setting the configuration (vnetPrivatePortCount to 2)

[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.

[vdx660]

We are also experiencing this bug

Error message: correlationId='e97825dd-01e6-4dfd-9b93-a2aec974b428', operationName='serviceBus.ServiceBusServiceOperationsProvider.ExecuteOperationOnMessageReceivedLogicAppPlatformOperations', message='Cached receiver not found for message id '9d9dcae7326443c38f3e4d78069dd0b7' from available cache contexts to perform operation 'completeMessage'.', exception='Microsoft.Azure.Workflows.ServiceProviders.Abstractions.ServiceOperationsProviderException: The Service Bus receiver was not found to perform operation 'completeMessage' on message id '5115677d-c322-4c35-b377-524490118728'.', organizationId='', activityVector='IN.C0', additionalProperties='{"ParentActivityId":"00-5115677d-c322-4c35-b377-524490118728-22f3acc987603afe-00"}', extensionVersion='1.70.60.0', siteName='logic-cc-sync', slotName='Production', activityId='573c84f1-443d-4d95-8be8-ee57d80f1c24'.