Honor [FromKeyedServices] on constructor parameters in generated code

[jeremydmiller]

Fixes the root cause of JasperFx/wolverine#3081: Wolverine handler code generation ignored [FromKeyedServices] on a handler's constructor parameters.

Root cause

ConstructorFrame.FindVariables resolved each constructor parameter by type only:

Parameters[i] = chain.FindVariable(parameter.ParameterType);

That discards the ParameterInfo and the attributes on it, so the [FromKeyedServices("…")] key was dropped. The parameter fell through to the default registration — meaning two keyed parameters of the same service type both resolved to whichever registration was last (the family default).

This only affected constructor injection. Method parameters already worked, because MethodCall.FindVariables resolves via the attribute-aware chain.FindVariable(ParameterInfo) overload that MethodFrameArranger uses to detect [FromKeyedServices] and resolve the keyed service. That asymmetry is exactly why keyed services on a Handle(...) method parameter worked in Wolverine but the same attribute on the handler's constructor silently resolved to the wrong instance.

Fix

One line — ConstructorFrame now uses the same ParameterInfo overload as MethodCall:

- Parameters[i] = chain.FindVariable(parameter.ParameterType);
+ Parameters[i] = chain.FindVariable(parameter);

Non-keyed parameters are unaffected: MethodFrameArranger.FindVariable(ParameterInfo) falls through to the type-based resolution when there is no attribute (and name-matches a same-typed variable, consistent with how method parameters already resolve).

Test

keyed_constructor_injection (in CodegenTests/Services) mirrors the existing keyed_service_location harness but exercises the constructor path via ServiceContainer.TryCreateConstructorFrames — the exact path Wolverine uses to build a handler instance. A class with two [FromKeyedServices] constructor parameters of the same service type:

• each_keyed_constructor_parameter_resolves_to_its_own_registration — the generated code references both implementations (before the fix, only the last/default appeared);
• keyed_constructor_parameters_resolve_correctly_at_runtime — compiles and runs the generated harness and asserts each parameter lands the correct keyed instance in the correct slot.

Both fail without the fix. Full CodegenTests Services/codegen/frames suite (406 tests) is green; the existing keyed_service_location tests still pass.

Follow-up

Once this is published, a follow-up PR to Wolverine will bump the JasperFx dependency and add an end-to-end reproduction test for #3081 (keyed constructor injection through a Wolverine handler, including under Lamar — whose keyed resolution is already correct).

🤖 Generated with Claude Code