Durable tasks using the class-based syntax are no longer discovered with Microsoft.Azure.Functions.Worker.Sdk 1.16.0+

[BrianWhiting]

I wasn't sure whether to post this issue here or in the Azure Functions project, so I'm posting it both places (other issue here: Azure/azure-functions-dotnet-worker#2067).

I'm currently using durable tasks in one of my projects with the class-based syntax provided through the Microsoft.DurableTask.Generators preview package (https://github.com/microsoft/durabletask-dotnet#class-based-syntax). When I upgrade Microsoft.Azure.Functions.Worker.Sdk from 1.15.1 to 1.16.0+, the runtime no longer discovers the orchestration triggers or activity triggers that are generated in the project.

Using 1.15.1:

Using 1.16.0+ (1.16.0, 1.16.1, and 1.16.2):

[jviau]

Pasting my comment from the other issue here:

The cause of this issue is that when using the class-based syntax and the durable generator, the functions that need to be indexed are emitted as part of source gen. But our function indexing itself also occurs during source-gen. This may be just an unsupported scenario and you need to revert to the old-style indexing (setting FunctionsEnableWorkerIndexing to false as others have mentioned).

I don't see this being solvable with the code-gen way as it is twofold issue:

1. I don't know if one source generator can even access emitted code from another source generator.
2. We cannot order/chain source generators, so no guarantee the durable generator will always run before the functions indexing generator.

I have been wanting to remove the need for a durable source generator to use class-based syntax for a bit now, and this is another good motivator for that. Not sure what the priority on that is, will need to discuss internally. But for now you correct workaround is to disable the new indexer.

[jviau]

Workaround is to add <FunctionsEnableWorkerIndexing>false</FunctionsEnableWorkerIndexing> to your project.

[snerte]

Workaround is to add <FunctionsEnableWorkerIndexing>false</FunctionsEnableWorkerIndexing> to your project.

This does show Orchestrations for me, but they are not triggered! Bewarned!

[martinlingstuyl]

Same here. It does add a line or 2 to the log say the orchestrator is Executing and Executed. But that's all it does. While the orchestration was working fine before I migrated to class based.
I fear I'll be migrating back till this is solved.

[tonyperez-dp]

Workaround is to add <FunctionsEnableWorkerIndexing>false</FunctionsEnableWorkerIndexing> to your project.

This does show Orchestrations for me, but they are not triggered! Bewarned!

I am seeing the same behavior. Is there an ETA as to when this will be addressed?

[GeoffreyJKing]

Same behavior here and the FunctionsEnableWorkerIndexing workaround doesn't work (orchestrators show up as registered but don't actually run). Given how much time I wasted on this, the class-based syntax should be removed from this page: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-dotnet-isolated-overview#class-based-example

[etheone]

I'm inclined to agree with the previous speaker. Should be removed from the documentation or at least marked as not production ready.

Is there any work at all being done on this? It has been open for over a year now. We're stuck using very old versions due to the class based syntax no longer being discovered.

We're itching to upgrade due to using the old versions seems to be the cause of this startup issue when deployed to azure which seems to be the root cause of the following issue.

[BrianWhiting]

I built a workaround to this issue a few weeks ago based on the internal code generation that the class-based syntax library uses. It doesn't require the use of classes, just functions decorated with the Function attribute with appropriate durable task parameters.

It solves the issue that the class-based syntax library has by not relying on the source generators to create the actual functions (since the Azure function framework also uses source generators to build some bootstrapping code and doesn't see the functions that the class-based syntax library generates), but instead it generates extension methods that just wrap the string-based calls to the durable task framework with strongly-typed methods.

I've been running it on an internal project for a couple weeks without any issues so far.

I put together a small example repo that you can use for yourself: https://github.com/BrianWhiting/DurableTasksSourceGeneratorExample

If you have the source generator project in the same solution as your durable task project, you need to add OutputItemType="Analyzer" ReferenceOutputAssembly="false" to your project reference in your .csproj file. See here: https://github.com/BrianWhiting/DurableTasksSourceGeneratorExample/blob/d6eb463207afe7f8a3bbf1578fd74b090f8a52cc/AzureFunctions/AzureFunctions.csproj#L18

[shibayan]

I have found a workaround that works with the latest SDK, so I'd like to share it.

    <FunctionsEnableWorkerIndexing>false</FunctionsEnableWorkerIndexing>
    <FunctionsEnableExecutorSourceGen>false</FunctionsEnableExecutorSourceGen>

[snerte]

I have found a workaround that works with the latest SDK, so I'd like to share it.

<FunctionsEnableWorkerIndexing>false</FunctionsEnableWorkerIndexing>
<FunctionsEnableExecutorSourceGen>false</FunctionsEnableExecutorSourceGen>

I can confirm that this works, orchestrations and activities are visible! I'm using these pkg versions:

    <PackageVersion Include="Microsoft.Azure.Functions.Worker" Version="2.0.0" />
    <PackageVersion Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.2.1" />
    <PackageVersion Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
    <PackageVersion Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.1" />
    <PackageVersion Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.0" OutputItemType="Analyzer" />
    <PackageVersion Include="Microsoft.DurableTask.Generators" Version="1.0.0-preview.1" />

[christophwille]

@cgillum could you chime in on the (architectural) future of this durable tasks generator library? Is this still the way forward, stalled, deprecated, ...? Thanks.

[cgillum]

Thanks for tagging me, and apologies for missing this discussion thread. I agree with the suggestion to remove the class-based syntax from the documentation. The feature unfortunately conflicts with the improvements that the .NET Isolated worker team (of which @jviau is a member) is trying to build, making it somewhat unviable moving forward (and one of the main reasons why this package still has a preview label).

That said, this generator library will continue to exist. We may end up removing support for class-based syntax, but will continue to support generating strongly typed extension methods for invoking activities, orchestrations, and hopefully soon entities. The source generator already knows how to work with ordinary function definitions today and we want to continue supporting this.

[julealgon]

@cgillum what would your recommendation be for someone to ensure they are up to date in regards to those decisions you mentioned?

We've started using class-based functions in a couple small projects on our side and I would like to make sure we are not using anything that is considered deprecated or that won't be supported in the future moving forward, but I also want those benefits that you mentioned in terms of generation of method calls as those make the code a lot cleaner for us.

Is there a migration path you guys are going to document for someone like us?

[jviau]

I am working on adding an extensibility point to the dotnet worker which will enable durable to add class-based syntax that is compatible with the existing source gen. No ETA on it, but it is on my radar to keep moving forward.

Azure/azure-functions-dotnet-worker#2834