All committers have signed the CLA.

Thanks! Hrmm, I am unsure we want to provide an async local form of what users can provide themselves. .NET expects, if you want access to the service provider, you inject it like anything else. Why not just accept service provider in the activity class constructor if you need it? Something like:

public class MyActivities
{
    private readonly IServiceProvider serviceProvider;
    private readonly IWhateverElse whateverElse;

    public MyActivities(IServiceProvider serviceProvider, IWhateverElse whateverElse)
    {
        this.serviceProvider = serviceProvider;
        this.whateverElse = whateverElse;
    }

    [Activity]
    public string DoMyActivity(string someParam)
    {
        // serviceProvider available here
        throw new NotImplementedException("TODO");
    }
} 

This way IServiceProvider is not special, it's just injected like anything else might be. If you as a user wanted to put some injected thing (like service provider) into an async local, you can.

@cretz, thanks for the suggestion, but how do I that with an interceptor?

The issue I'm trying to find a solution for relates to handling a cross-cutting concern that would need to be handled in every Activity.

For example, consider adding support for OpenTelemetry in every Activity compared to adding support for OpenTelemetry via an interceptor that allows each Activity to be agnostic of OpenTelemetry and to instead focus on its actual job.

Support for OpenTelemetry avoids needing DI because diagnostic activities don't require a reference to the specific trace provider. But if that weren't the case, if supporting OpenTelemetry required the interceptor to have a reference to the specific trace provider and that trace provider were only accessible via the service provider, how would support for OpenTelemetry be handled other than by adding logic to every Activity to handle OpenTelemetry concerns via the injected IServiceProvider? It would no longer be a problem that could be solved with an interceptor.

Put another way, if there's some common, scoped service registered with the IServiceProvider, why should I have to add logic to every Activity in order to handle setup/teardown with that scoped service?

Put yet another way, if I were making a library for use with Temporal, how could I provide a library that depended on a scoped service from IServiceProvider and didn't need to be explicitly called in every Activity?

thanks for the suggestion, but how do I that with an interceptor?

An interceptor cannot control what an activity implementer chooses to dependency inject. This same concern occurs with anything to dependency inject not just service provider.

Support for OpenTelemetry avoids needing DI because diagnostic activities don't require a reference to the specific trace provider. But if that weren't the case, if supporting OpenTelemetry required the interceptor to have a reference to the specific trace provider and that trace provider were only accessible via the service provider, how would support for OpenTelemetry be handled other than by adding logic to every Activity to handle OpenTelemetry concerns via the injected IServiceProvider?

DI is optional in .NET and I believe the reason that OpenTelemetry and .NET diagnostic activities use a shared tracer provider and shared .NET diagnostic activity sources is because the per-DI-scope design is too limiting for general purpose use. I wonder if your use case could not rely on optional DI and scoping the same way OTel does not.

why should I have to add logic to every Activity in order to handle setup/teardown with that scoped service?

Because it is a specific need in your case to have implicit access to the DI container in a non-DI instantiated interceptor. One approach may be leveraging IServiceScopeFactory to set your async local. For example, maybe something like:

public class MyServiceScopeFactory : IServiceScopeFactory
{
    public static readonly AsyncLocal<IServiceProvider> CurrentServiceProvider = new();

    private readonly IServiceScopeFactory underlying;

    public MyServiceScopeFactory(IServiceScopeFactory underlying) => this.underlying = underlying;

    public IServiceScope CreateScope()
    {
        var scope = underlying.CreateScope();
        CurrentServiceProvider.Value = scope.ServiceProvider;
        return scope;
    }
}

And change host builder to have something like .ConfigureServices(services => services.AddSingleton<IServiceScopeFactory>(provider => new MyServiceScopeFactory(provider.GetRequiredService<IServiceScopeFactory>())) but I have not tested it.

The other option we'd entertain is a way to make the activity inbound interceptor be created in the current scope. My concern is exposing a static based on async local if we don't have to, but maybe we can have some ITemporalWorkerServiceOptionsBuilder extension like .AddScopedActivityInterceptor<ActivityInboundInterceptor> that we make sure somehow to instantiate with the service provider. I suspect we'd have to use ActivatorUtilities.CreateInstance to be able to provide the next interceptor. Maybe it would be powered internally by async local (i.e. an internal interceptor with static async local that is set the way this PR does, but remains internal). I would have to sit down and design this a bit.

Hey @cretz , thanks for the thorough response.

I like your IServiceScopeFactory idea and have explored it, but it doesn't seem to be supported.

I'm out of time for this today, but will respond to your other comments later this week. ❤️

Interesting. So I am now starting to lean towards providing the service provider in the interceptor only. Meaning I wonder if we should keep this async local internal and have something like:

namespace Temporalio.Extensions.Hosting;

interface IWorkerInterceptorWithServiceProvider : IWorkerInterceptor
{
    ActivityInboundInterceptor InterceptActivity(ActivityInboundInterceptor nextInterceptor) =>
        InterceptActivity(WhateverInternalAsyncLocal.Value, nextInterceptor);

    ActivityInboundInterceptor InterceptActivity(IServiceProvider serviceProvider, ActivityInboundInterceptor nextInterceptor) =>
        nextInterceptor;
}

My main concern is I am not wanting people to generally use an async local to access the scope or service provider inside the activity if we can help it. I agree that constructor injection doesn't work with interceptors, so maybe this can work around it this way (still using async local internally though).