Authorization problem when using tracking store with large messages #2235
Unanswered
flavio-vgt
asked this question in
Q&A
Replies: 1 comment 1 reply
-
Hi @flavio-vgt, Thanks for reaching out. This sounds like an edge-case that should be called out in our docs. I'm surprised that giving storage account access to the Application Router is not sufficient, though admittedly I'm not terribly familiar with this deployment scenario. I'm gonna have to defer to @amdeel and @cgillum in case they're familiar with this one. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
We implemented the Application Routing for zero downtime deployments. In there we configured all the deployments to use the same tracking store, so we can list the instances over all versions as shown here.
Because we want to list the instances and show them to our users, we coded a cloud function which sits in the Application Router function app and uses the IDurableOrchestrationClient to get all the instances (with some filtering). For this to work we also configured the tracking store of the Application Router to be the same as the versioned function apps which run the orchestrator functions.
This worked very reliable so far. The problem which occurred now is that when the output of an orchestrator is too big, it saves it in the output as a blob in the storage account of the function app and not the tracking store (ex. Storage Account C in the image above). When we now want to list the instances from the Application Router, we get an error (Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.) because the Application Router does not have permission to read from the storage accounts where the large message blob is stored (ex. Storage Account C).
We tried to grant the Application Router permissions to the storage accounts (ex. A-C) via resource groups and even directly, but the error stays the same.
Do you have any recommendations on how to deal with this scenario or do you plan on saving large messages in the blob storage of the tracking store when one is configured?
Beta Was this translation helpful? Give feedback.
All reactions