Edit

Troubleshoot errors in Durable Task Scheduler

This article helps you troubleshoot common scenarios in Durable Task Scheduler apps. Find your scenario in the following list and follow the linked steps to diagnose and resolve the issue.

Common scenarios

Note

Microsoft support engineers are available to help diagnose issues with your application. If you're not able to diagnose your problem after going through this article, you can file a support ticket by going to the Help > Support + troubleshooting section of the Durable Task Scheduler resource in the Azure portal.

Check connection string and access to Durable Task Scheduler

When your app isn't running as expected, verify the following:

  • The connection string format is correct.
  • Authentication is set up correctly.

Local development

  1. Check the connection string, which should have this format: Endpoint=http://localhost:<port number>;Authentication=None. Ensure the port number is the one mapped to 8080 on the container running the durable task scheduler emulator.

  2. Along with the durable task scheduler emulator, make sure the Azure Storage emulator, Azurite, is started. Azurite is needed for components of the app related to Functions.

Running on Azure

  1. Check your app for the environment variables DURABLE_TASK_SCHEDULER_CONNECTION_STRING and TASKHUB_NAME.

  2. Check the value of DURABLE_TASK_SCHEDULER_CONNECTION_STRING. Specifically, verify that the scheduler endpoint and authentication type are correct. The connection string should be formatted as follows when using:

    • User-assigned managed identity: Endpoint={scheduler endpoint};Authentication=ManagedIdentity;ClientID={client id}, where client id is the identity's client ID.
    • System-assigned managed identity: Endpoint={scheduler endpoint};Authentication=ManagedIdentity
  3. Ensure the required role-based access control (RBAC) permission is granted to the identity needing to access the specified task hub or scheduler.

  4. If user-assigned managed identity is used, ensure the identity is assigned to your app.

Error deploying Durable Functions app to Azure

If your deployment fails with an error such as Encountered an error (ServiceUnavailable) from host runtime from Visual Studio Code, first check your app to ensure the required environment variables are set correctly. Then redeploy your app. If you see an error loading functions, select the Refresh button.

Unknown error retrieving details of this task hub

If you get an Unknown error retrieving details of this task hub error on the durable task scheduler dashboard, the reason could be:

  1. Your identity (email) doesn't have the required permission assigned for that task hub. Follow instructions to grant the permission, then access the dashboard again.

  2. Your task hub was deleted.

Can't delete resource

Before you can delete a scheduler resource, you must first delete all of its task hubs. If you haven't, you receive the following error message:

{
  "error": {
    "code": "CannotDeleteResource",
    "message": "Cannot delete resource while nested resources exist. Some existing nested resource IDs include: 'Microsoft.DurableTask/schedulers/YOUR_SCHEDULER/taskhubs/YOUR_TASKHUB'. Please delete all nested resources before deleting this resource."
  }
}

To resolve this, list the task hubs in the scheduler and delete them:

# List all task hubs in the scheduler
az durabletask taskhub list --resource-group RESOURCE_GROUP_NAME --scheduler-name SCHEDULER_NAME

# Delete each task hub
az durabletask taskhub delete --resource-group RESOURCE_GROUP_NAME --scheduler-name SCHEDULER_NAME --name TASKHUB_NAME

After all task hubs are deleted, retry deleting the scheduler resource.

Can't determine project to build

If, after starting Azurite, you encounter the error: “Can't determine Project to build. Expected 1 .csproj or .fsproj but found 2”:

  • Delete the bin and obj directories in your app.
  • Try running func start again.

Can't find native binaries for ARM (Apple silicon)

If you see gRPC errors related to not finding native binaries for ARM (such as on an Apple silicon Mac — M1, M2, etc.), add the following workaround to your extensions.csproj file:

  1. Add a package reference to Contrib.Grpc.Core.M1.
  2. Add a custom after-build target that copies the ARM64 gRPC native libraries to the correct output directory.

Add the following ItemGroup and Target elements to your extensions.csproj:

<!-- Workaround for gRPC issues on ARM (Apple silicon) devices -->
<ItemGroup>
  <PackageReference Include="Contrib.Grpc.Core.M1" Version="2.41.0" />
</ItemGroup>
<Target Name="CopyGrpcNativeAssetsToOutDir" AfterTargets="Build">
  <ItemGroup>
    <NativeAssetToCopy Condition="$([MSBuild]::IsOSPlatform('OSX'))" Include="$(OutDir)runtimes/osx-arm64/native/*"/>
  </ItemGroup>
  <Copy SourceFiles="@(NativeAssetToCopy)" DestinationFolder="$(OutDir).azurefunctions/runtimes/osx-arm64/native"/>
</Target>