Codegen: concrete + interface both on AlwaysUseServiceLocationFor generate the same local name (CS0128)

[booleanAP]

Describe the bug

When both a concrete type and its interface are on the AlwaysUseServiceLocationFor allow-list, and one handler chain needs both, the generator emits two locals with the same name and the chain fails to compile:

CS0128: A local variable or function named 'callerContext' is already defined in this scope
CS1503: Argument 3: cannot convert from 'MyApp.Auth.ICallerContext' to 'MyApp.Auth.CallerContext'

The local name appears to be derived from the type name with a leading I stripped, so CallerContext and ICallerContext both become callerContext. The second error follows from the first: the call site then binds the wrong variable.

Why both are on the list. CallerContext is scoped and mutable — one instance per message scope, populated by the handler that scopes it to a tenant — so the generator emitting new CallerContext() would break the single-instance-per-scope invariant. ICallerContext is a read-only view over that same instance, registered as AddScoped<ICallerContext>(sp => sp.GetRequiredService<CallerContext>()), which is a lambda factory and therefore opaque. Both genuinely have to come from the scope, and both are reachable from one chain: the handler wrapper takes the writable type, and a service in the graph beneath it takes the read-only one.

Registrations

services.AddScoped<CallerContext>();
services.AddScoped<ICallerContext>(sp => sp.GetRequiredService<CallerContext>());

opts.CodeGeneration.AlwaysUseServiceLocationFor<CallerContext>();
opts.CodeGeneration.AlwaysUseServiceLocationFor<ICallerContext>();

Shape that triggers it — a handler whose own dependency takes ICallerContext, wrapped by something taking CallerContext:

public sealed class MemberScreeningCache(ModularDbContext db, ICallerContext caller) : IMemberScreeningCache;

public sealed class UpdateMemberScreeningCache(IMemberScreeningCache cache, ILogger<UpdateMemberScreeningCache> logger)
    : IDomainEventHandler<ScreeningRunCompleted>;

// the wrapper Wolverine actually routes to, which takes the writable caller
public sealed class DomainEventBridge<T>
{
    public Task Handle(T evt, IEnumerable<IDomainEventHandler<T>> handlers, CallerContext caller, ILogger logger, CancellationToken ct);
}

Generated code (trimmed; dotnet run -- codegen test):

await using var serviceScope = _serviceScopeFactory.CreateAsyncScope();

// This service has been marked as requiring service location ...
var callerContext = ServiceProviderServiceExtensions
    .GetRequiredService<MyApp.Auth.ICallerContext>(serviceScope.ServiceProvider);

var memberScreeningCache = new MemberScreeningCache(modularDbContext, callerContext);
var updateMemberScreeningCache = new UpdateMemberScreeningCache(memberScreeningCache, _logger);

IEnumerable<IDomainEventHandler<ScreeningRunCompleted>> handlers =
    new IDomainEventHandler<ScreeningRunCompleted>[]{ updateMemberScreeningCache, ... };

// This service has been marked as requiring service location ...
var callerContext = ServiceProviderServiceExtensions          // <-- CS0128
    .GetRequiredService<MyApp.Auth.CallerContext>(serviceScope.ServiceProvider);

await bridge.Handle(evt, handlers, callerContext, _logger, cancellation);  // <-- CS1503

Expected behavior

Two distinct service types should get two distinct local names — e.g. suffixing on collision (callerContext2), or deriving the name from the full type name rather than the interface-stripped one.

Why it is easy to miss

The failure surfaces when a chain is resolved, not when the host starts. With TypeLoadMode.Dynamic that is on first message, so:

• host startup is clean,
• the publisher commits its work and returns success,
• the handler never runs, and its own logging never fires,
• nothing is dead-lettered, because the envelope never reached a handler.

In our case a projection handler silently stopped running and the only visible symptom was a stale read model. dotnet run -- codegen test catches it, and we have added that to CI, but the runtime symptom is entirely silent — so a naming collision reads as a working system.

Version

• WolverineFx 6.21.0 (WolverineFx.SqlServer, WolverineFx.EntityFrameworkCore, WolverineFx.RuntimeCompilation)
• JasperFx 2.30.1
• .NET 10

Related but not the same

• Wolverine codegen - variable name used twice in codegen #312 — same C# error, different cause (two handler types sharing a short name, v0.9).
• Incorect codegen with AlwaysUseServiceLocationFor #1935 — also AlwaysUseServiceLocationFor, but about which services get located rather than what they are named.

Workaround

Name a contract higher up the graph on the allow-list so the generator stops descending before it reaches both caller types.

[jeremydmiller]

@booleanAP WHY ARE YOU DOING THAT???

[jeremydmiller]

You can work around this w/ a custom IVariableSource for both CallerContext and the ICallerContext. Or really just make ICallerContext a "derived variable". Wolverine has chugged along for years without anyone needing to do this, and I'm not enthusiastic about making big changes just to accommodate this.

Converting to a discussion.

[booleanAP]

Yeah closing this, lol. Was spiking an implementation, sorry for the noise 😞