Note: This post assumes Azure Table Storage is the backend data store.
Finding The InstanceId
A good first step is finding the
InstanceId if you don’t already have it. This is the
PartitionKey for table storage which can filter the tables for this specific instance.
In table storage you’ll find two tables, one ending in
History and one ending in
Instances can be helpful for determining the
InstanceId, as the
InstanceId is the
PartitionKey in table storage and it contains the input parameters for each instance.
Note: If multiple Azure Functions applications are running the same code but using their own backend state storage for Durable Functions you’ll need to find which web app is handling the Durable Functions instance. You can guess and check Table Storage or query Application Insights for the
appName using an Instance summary query.
Here’s a few options:
- View Table Storage directly: A quick option is browsing to table storage directly via the Azure portal. Navigate the storage account on the Azure portal, open Storage Explorer on the left pane, expand Tables, view the
Instancetables filtering by
- Durable Functions Monitor: Per the repository README.md: “A monitoring/debugging UI tool for Azure Durable Functions”. There’s different options for running it, including a Visual Studio Code extension.
- Azure Functions Core Tools: If you prefer the command line check out this docs page, noting the “Azure Functions Core Tools” headings: Manage instances in Durable Functions in Azure. Run the commands from the root folder of the Azure Functions application. For non-local debugging you’ll need to update the storage connection string. By default, it uses the
AzureWebJobsStoragestorage connection string but can be overridden.
- Application Insights: If data is being logged to Application Insights you can run queries. For example, Instance summary query “… displays the status of all orchestration instances that were run in a specified time range.” which you may find useful if you’re looking for a high level view, which can help bridge between multiple Azure Functions applications running the same code.
Thoughts For Future Debugging
After you’ve worked through an issue you have an opportunity to potentially make a similar investigation easier next time.
- Would setting a Custom Status help?
- If it’s a fan-out/fan-in operation would enhancing exception messages with the HTTP verb, url, and information about the response help (HTTP status code or perhaps even the response body, depending on confidentiality concerns with logging the response content)? You may find my Debugging Fan-Out Operation Failures With Custom Exception Messages Using Durable Functions Extension For Azure Functions On C# post useful if that sounds helpful.
Hope this helps if you’re investigating an issue!