Add AddTasksAsServices extension for registering DurableTask types in DI container #577

Copilot · 2025-12-18T11:32:44Z

Summary

What changed?

Added AddTasksAsServices extension method on IDurableTaskWorkerBuilder that registers all task types (activities, orchestrators, entities) as transient services in the DI container
Added internal HashSet<Type> collections in DurableTaskRegistry to track types registered via type-based methods (AddActivity(Type), AddOrchestrator(Type), AddEntity(Type))
Added 7 unit tests covering all scenarios: type registration, singleton instances, function-based tasks, and worker integration

Why is this change needed?

This enables DurableTask types to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime. This follows the same pattern as ASP.NET Core's AddControllersAsServices() extension.

Issues / work items

Related Allow registering Function classes as services in the container #88

Project checklist

Release notes are not required for the next release
Backport is not required
All required tests have been added/updated (unit tests, E2E tests)
Breaking change? No

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

No
Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
Yes, an AI agent generated most of this PR

If AI was used:

Tool(s): GitHub Copilot Agent
AI-assisted areas/files:
- src/Abstractions/DurableTaskRegistry.cs - Added HashSet tracking for registered types
- src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs - Added AddTasksAsServices extension
- test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs - Added comprehensive unit tests
What you changed after AI output:
- Updated HashSet initialization from collection expression [] to new HashSet<Type>() to new() based on code review feedback
- Added test for singleton instance registration behavior based on code review feedback

AI verification (required if AI was used):

I understand the code and can explain it
I verified referenced APIs/types exist and are correct
I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
I reviewed concurrency/async behavior
I checked for unintended breaking or behavior changes

Testing

Automated tests

Result: Passed (75 Worker.Tests pass including 7 new AddTasksAsServices tests)

Manual validation (only if runtime/behavior changed)

N/A (unit tests provide sufficient coverage)

Notes for reviewers

Only types registered via type-based methods (e.g., AddActivity<T>(), AddOrchestrator<T>()) are registered in DI
Types registered via factory methods or singleton instances are NOT registered in DI (by design)
The extension also calls AddTasks() internally, so tasks are registered with both DI and the worker
Usage example:

builder.Services.AddDurableTaskWorker()
    .AddTasksAsServices(tasks =>
    {
        tasks.AddActivity<MyActivity>();
        tasks.AddOrchestrator<MyOrchestrator>();
        tasks.AddEntity<MyEntity>();
    });

Original prompt

This section details on the original issue you should resolve

<issue_title>[Request] Add extension to register all functions as services in DI container</issue_title>
<issue_description># Proposal

Introduce a new AddFuncitonsAsServices extension method on IFunctionsWorkerApplicationBuilder that automatically registers every function class detected by the functions framework in the dependency injection container.

This allows all function classes to participate in the container's self-checking logic during startup of the project, preventing runtime errors much later when actually executing specific functions if dependencies cannot be resolved.

Background

AspNetCore MVC provides a AddControllersAsServices() extension that registers all controllers in the container automatically.

This not only enables things such as being able to decorate controller classes via the container, but more importantly it allows controller classes to participate in the Microsoft DI container self-checking mechanism, which iterates through all services registered in the container and checks whether or not their dependencies can be resolved. This mechanism is enabled by default while in debug mode and allows developers to catch DI-related errors much earlier in the pipeline: the validation error is raised during container construction, instead of only during a specific call to the affected controller action.

My proposal is that a similar extension be created for functions/durable functions, which would allow consumers to easily add all functions as services. A potential name for such extension could be AddFuncitonsAsServices(), for consistency.

While consumers can register functions manually themselves and still have them participate in the container self-check process, this approach is error-prone, creates coupling with the durable tasks library, and potentially duplicates logic: users would be tasked with creating their own logic to "detect" all function classes, which is something that the functions framework already does to perform its main job. The alternative is to manually register each individual function as separate calls, which not only doesn't scale well, but is fairly noisy, leads to situations where some functions are forgotten to be registered (which could then potentially lead to runtime issues being detected only after deployment), and also forces developers to remember to add a registration whenever they create a new function.

If the team is resistant to adding such helper extension, the framework should at least expose discovered functions in some sort of callback so that consumers could then register those types themselves without having to replicate the function detection logic.

This is a spin-off of:

Allow registering Function classes as services in the container #88</issue_description>

Comments on the Issue (you are @copilot in this section)
@jviau Oh, your request is for Azure Functions as a whole and not just Durable. This request would belong in https://github.com/Azure/azure-functions-dotnet-worker
However, there would be an applicable request for Durable as well, for registering all tasks on DurableTaskRegistry to the IServiceCollection. This issue can be repurposed for that functionality request.</comment_new>

Fixes [Request] Add extension to register all functions as services in DI container #107

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Co-authored-by: YunchuWang <12449837+YunchuWang@users.noreply.github.com>

Copilot

Pull request overview

This PR adds the AddTasksAsServices extension method to enable DurableTask types (activities, orchestrators, entities) to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime.

Key Changes:

Added internal HashSet collections in DurableTaskRegistry to track types registered via type-based methods
Implemented AddTasksAsServices extension that extracts registered types and registers them as transient services
Added comprehensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Abstractions/DurableTaskRegistry.cs	Added internal HashSet properties to track activity, orchestrator, and entity types
src/Abstractions/DurableTaskRegistry.Activities.cs	Modified `AddActivity(TaskName, Type)` to track type in ActivityTypes collection
src/Abstractions/DurableTaskRegistry.Orchestrators.cs	Modified `AddOrchestrator(TaskName, Type)` to track type in OrchestratorTypes collection
src/Abstractions/DurableTaskRegistry.Entities.cs	Modified `AddEntity(TaskName, Type)` to track type in EntityTypes collection
src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs	Added `AddTasksAsServices` extension method with XML documentation and implementation
test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs	Added comprehensive test suite including tests for activities, orchestrators, entities, function-based tasks, and worker registration

Copilot · 2025-12-31T20:47:49Z

src/Abstractions/DurableTaskRegistry.cs

+    internal HashSet<Type> ActivityTypes { get; } = new HashSet<Type>();
+
+    /// <summary>
+    /// Gets the types of registered orchestrators.
+    /// </summary>
+    internal HashSet<Type> OrchestratorTypes { get; } = new HashSet<Type>();
+
+    /// <summary>
+    /// Gets the types of registered entities.
+    /// </summary>
+    internal HashSet<Type> EntityTypes { get; } = new HashSet<Type>();


The HashSet initialization should use target-typed new() syntax instead of the explicit type for consistency with other similar patterns in the codebase (e.g., GrpcDurableTaskWorkerOptions.cs:32). This follows the C# 9.0 target-typed new expressions pattern that's already used in this codebase.

Suggested change

internal HashSet<Type> ActivityTypes { get; } = new HashSet<Type>();

/// <summary>

/// Gets the types of registered orchestrators.

/// </summary>

internal HashSet<Type> OrchestratorTypes { get; } = new HashSet<Type>();

/// <summary>

/// Gets the types of registered entities.

/// </summary>

internal HashSet<Type> EntityTypes { get; } = new HashSet<Type>();

internal HashSet<Type> ActivityTypes { get; } = new();

/// <summary>

/// Gets the types of registered orchestrators.

/// </summary>

internal HashSet<Type> OrchestratorTypes { get; } = new();

/// <summary>

/// Gets the types of registered entities.

/// </summary>

internal HashSet<Type> EntityTypes { get; } = new();

This was already addressed in commit b490b9c which changed the HashSet initialization to use target-typed new() syntax.

Copilot · 2025-12-31T20:47:49Z

src/Abstractions/DurableTaskRegistry.cs

+    internal HashSet<Type> ActivityTypes { get; } = new HashSet<Type>();
+
+    /// <summary>
+    /// Gets the types of registered orchestrators.
+    /// </summary>
+    internal HashSet<Type> OrchestratorTypes { get; } = new HashSet<Type>();
+
+    /// <summary>
+    /// Gets the types of registered entities.
+    /// </summary>
+    internal HashSet<Type> EntityTypes { get; } = new HashSet<Type>();


The HashSet initialization should use target-typed new() syntax instead of the explicit type for consistency with other similar patterns in the codebase (e.g., GrpcDurableTaskWorkerOptions.cs:32). This follows the C# 9.0 target-typed new expressions pattern that's already used in this codebase.

Suggested change

internal HashSet<Type> ActivityTypes { get; } = new HashSet<Type>();

/// <summary>

/// Gets the types of registered orchestrators.

/// </summary>

internal HashSet<Type> OrchestratorTypes { get; } = new HashSet<Type>();

/// <summary>

/// Gets the types of registered entities.

/// </summary>

internal HashSet<Type> EntityTypes { get; } = new HashSet<Type>();

internal HashSet<Type> ActivityTypes { get; } = new();

/// <summary>

/// Gets the types of registered orchestrators.

/// </summary>

internal HashSet<Type> OrchestratorTypes { get; } = new();

/// <summary>

/// Gets the types of registered entities.

/// </summary>

internal HashSet<Type> EntityTypes { get; } = new();

This was already addressed in commit b490b9c which changed the HashSet initialization to use target-typed new() syntax.

src/Abstractions/DurableTaskRegistry.cs

Copilot · 2025-12-31T20:47:50Z

test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs

+    [Fact]
+    public void AddTasksAsServices_DoesNotRegisterFunctionBasedTasks()
+    {
+        // Arrange
+        ServiceCollection services = new();
+        DefaultDurableTaskWorkerBuilder builder = new("test", services);
+
+        // Act
+        builder.AddTasksAsServices(registry =>
+        {
+            registry.AddActivityFunc("testFunc", (TaskActivityContext ctx) => Task.CompletedTask);
+        });
+
+        // Assert - No exception should be thrown and no types should be registered
+        IServiceProvider provider = services.BuildServiceProvider();
+        // There should be no issue building the service provider
+        provider.Should().NotBeNull();
+    }


Consider adding a test case for singleton instance registration to verify that instances registered via AddActivity(ITaskActivity) are not added to the DI container, similar to the existing test AddTasksAsServices_DoesNotRegisterFunctionBasedTasks. This would provide complete coverage of the documented behavior that only type-based registrations are included.

Added test AddTasksAsServices_DoesNotRegisterSingletonInstances to verify singleton instances are not registered in DI container. Commit: 88c4998

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

YunchuWang · 2026-01-01T00:08:32Z

@copilot address comments

YunchuWang · 2026-01-01T00:08:42Z

@copilot update pr description to follow .github/PULL_REQUEST_TEMPLATE.md

Co-authored-by: YunchuWang <12449837+YunchuWang@users.noreply.github.com>

Copilot · 2026-01-01T00:12:10Z

@copilot address comments

All comments have been addressed:

HashSet initialization already uses target-typed new() syntax (commit b490b9c)
Added test for singleton instance registration behavior (commit 88c4998)

All 7 AddTasksAsServices tests pass.

Copilot · 2026-01-01T00:16:17Z

@copilot update pr description to follow .github/PULL_REQUEST_TEMPLATE.md

Updated PR description to follow the template in .github/PULL_REQUEST_TEMPLATE.md:

Summary

What changed?

Added AddTasksAsServices extension method on IDurableTaskWorkerBuilder that registers all task types (activities, orchestrators, entities) as transient services in the DI container
Added internal HashSet<Type> collections in DurableTaskRegistry to track types registered via type-based methods (AddActivity(Type), AddOrchestrator(Type), AddEntity(Type))
Added 7 unit tests covering all scenarios: type registration, singleton instances, function-based tasks, and worker integration

Why is this change needed?

This enables DurableTask types to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime. This follows the same pattern as ASP.NET Core's AddControllersAsServices() extension.

Issues / work items

Related Allow registering Function classes as services in the container #88

Project checklist

Release notes are not required for the next release
Backport is not required
All required tests have been added/updated (unit tests, E2E tests)
Breaking change? No

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

No
Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
Yes, an AI agent generated most of this PR

If AI was used:

Tool(s): GitHub Copilot Agent
AI-assisted areas/files:
- src/Abstractions/DurableTaskRegistry.cs - Added HashSet tracking for registered types
- src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs - Added AddTasksAsServices extension
- test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs - Added comprehensive unit tests
What you changed after AI output:
- Updated HashSet initialization from collection expression [] to new HashSet<Type>() to new() based on code review feedback
- Added test for singleton instance registration behavior based on code review feedback

AI verification (required if AI was used):

I understand the code and can explain it
I verified referenced APIs/types exist and are correct
I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
I reviewed concurrency/async behavior
I checked for unintended breaking or behavior changes

Testing

Automated tests

Result: Passed (75 Worker.Tests pass including 7 new AddTasksAsServices tests)

Manual validation (only if runtime/behavior changed)

N/A (unit tests provide sufficient coverage)

Notes for reviewers

Only types registered via type-based methods (e.g., AddActivity<T>(), AddOrchestrator<T>()) are registered in DI
Types registered via factory methods or singleton instances are NOT registered in DI (by design)
The extension also calls AddTasks() internally, so tasks are registered with both DI and the worker
Usage example:

builder.Services.AddDurableTaskWorker()
    .AddTasksAsServices(tasks =>
    {
        tasks.AddActivity<MyActivity>();
        tasks.AddOrchestrator<MyOrchestrator>();
        tasks.AddEntity<MyEntity>();
    });

YunchuWang · 2026-01-01T00:50:32Z

verified working as expected

Initial plan

6df155b

Copilot AI assigned Copilot and YunchuWang Dec 18, 2025

Copilot started work on behalf of YunchuWang December 18, 2025 11:33 View session

Copilot AI and others added 2 commits December 18, 2025 11:50

Add AddTasksAsServices extension method for DurableTaskWorkerBuilder

43d2be4

Co-authored-by: YunchuWang <12449837+YunchuWang@users.noreply.github.com>

Address code review feedback - use traditional HashSet syntax

8a6fd7a

Co-authored-by: YunchuWang <12449837+YunchuWang@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Add extension to register all functions as services in DI container~~ Add AddTasksAsServices extension for registering DurableTask types in DI container Dec 18, 2025

Copilot AI requested a review from YunchuWang December 18, 2025 11:58

Copilot finished work on behalf of YunchuWang December 18, 2025 11:58

YunchuWang added 2 commits December 19, 2025 16:42

Merge branch 'main' into copilot/add-functions-as-services-extension

5b64f4a

Merge branch 'main' into copilot/add-functions-as-services-extension

1082ff1

YunchuWang marked this pull request as ready for review December 31, 2025 20:43

Copilot AI review requested due to automatic review settings December 31, 2025 20:43

Copilot started reviewing on behalf of YunchuWang December 31, 2025 20:44 View session

Copilot AI reviewed Dec 31, 2025

View reviewed changes

Update src/Abstractions/DurableTaskRegistry.cs

b490b9c

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot started work on behalf of YunchuWang January 1, 2026 00:09 View session

Add test for singleton instance registration behavior

88c4998

Co-authored-by: YunchuWang <12449837+YunchuWang@users.noreply.github.com>

Copilot finished work on behalf of YunchuWang January 1, 2026 00:13

Copilot started work on behalf of YunchuWang January 1, 2026 00:13 View session

Copilot finished work on behalf of YunchuWang January 1, 2026 00:17

YunchuWang added the ready for review label Jan 1, 2026

Add AddTasksAsServices extension for registering DurableTask types in DI container #577

Are you sure you want to change the base?

Add AddTasksAsServices extension for registering DurableTask types in DI container #577

Uh oh!

Conversation

Copilot AI commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What changed?

Why is this change needed?

Issues / work items

Project checklist

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

Testing

Automated tests

Manual validation (only if runtime/behavior changed)

Notes for reviewers

Background

Comments on the Issue (you are @copilot in this section)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Dec 31, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

YunchuWang commented Jan 1, 2026

Uh oh!

YunchuWang commented Jan 1, 2026

Uh oh!

Copilot AI commented Jan 1, 2026

Uh oh!

Copilot AI commented Jan 1, 2026

Summary

What changed?

Why is this change needed?

Issues / work items

Project checklist

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

Testing

Automated tests

Manual validation (only if runtime/behavior changed)

Notes for reviewers

Uh oh!

YunchuWang commented Jan 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Dec 18, 2025 •

edited

Loading