0
votes

I'm having some trouble with my current architecture and I don't understand why...

I have 2 Azure Functions Apps (V1) sharing the same Storage Account. One of them is on Consumption Plan and the other on a App Service Plan.

I have the following scenario happening for one of the function in the Consumption Plan :

  • Read message from Queue
  • Depends on the reading, there are two choices :
    1. Direct call to an Orchestrator with the StartNewAsync() method
    2. Add a message in another Queue to start the Orchestrator on the App Service Plan

My problem is with the point 2.

The DurableOrchestrationClient on the App Service Plan is start, but it seems that there are problems between the 2 Functions Apps because in the Live Metrics Streams I'm getting a lot of message saying :

The function 'MyOrchestratorInAppServicePlan' doesn't exist, is disabled, or is not an orchestrator function. Additional info: The following are the active orchestrator functions: 'AllTheOrchestratorsIHaveInConsumptionPlan'.. InstanceId: 601afed81ad64a0aad87bb7984de4a94. Function: MyOrchestratorInAppServicePlan. HubName: DurableFunctionsHub. AppName: MyFunctionAppInConsumptionPlan. SlotName: Production. ExtensionVersion: 1.6.0. SequenceNumber: 47.

And they are not launch regularly it could take up to more than 30 minutes to really start the desired function, like the Functions App on the Consumption Plan is reading the messages that are not intended to it and my App Service Plan Functions App do nothing because it's already "treated" by the other (I think?).

Any help or advice would be really appreciated :D

EDIT : I'm able to launch the Orchestrator by restarting both Azure Functions App, but it does not always treat all the pending durable operation

EDIT 2 : I just saw that it does the same thing but revert in the case of point 1. The App Service Plan search for the other durable instead of the Consumption Plan.

1
Functions runtime acquires lease on the storage account attached to the function app using an unique Id that is specific to your function App. This is an internal implementation detail. It is not recommended to share storage account between functions apps. Can you different storage accounts?Pragna Gopa
That's my workaround for now, I use a different storage account. I just saw this issue that explained my problem, I didn't find it before. If I understand, I just have to define a specific HubName for 1 of my function app to make it work :github.com/Azure/azure-functions-durable-extension/issues/407Pierre Chételat

1 Answers

0
votes

The problem was that I didn't find this link before : https://github.com/Azure/azure-functions-durable-extension/issues/407

It was a known bug with a workaround