DetermineCallingAssembly returns intermediate Critter Stack assemblies, making the GH-3521 divergence warning fire on healthy hosts

[jeremydmiller]

Follow-up to #600 — same function, different failure mode. Where #600 is about the walk landing on a test runner, this is about it landing on an intermediate Critter Stack assembly, which makes the GH-3521 divergence warning unreliable as a diagnostic.

What I measured

Instrumenting Wolverine's twin of this logic on a fully green local run of one test shard: RegistrationCallingAssembly resolved to Wolverine.SqlServer on 81 of 82 hosts, not to the test assembly that actually called UseWolverine. Because the adopted application assembly was correctly PolecatTests, checkForDivergentApplicationAssembly compared Wolverine.SqlServer against PolecatTests, found them different, and raised the warning on all 81 — on a run where nothing was wrong.

The measurement is from Wolverine's copy of the walk. I have not instrumented JasperFx's directly, but the two are structurally identical (DetermineCallingAssembly → RegistrationCallingAssembly set in AddJasperFx → compared in checkForDivergentApplicationAssembly at JasperFxOptions.cs:171), and the cause applies equally: when a Critter Stack extension registers JasperFx on behalf of the application, the first non-System*/Microsoft* frame outside JasperFx belongs to the extension, not the app.

Why it matters

The warning exists to make a silent first-host-wins pin observable. Firing it on healthy hosts inverts that value:

• It trains readers to ignore it.
• Its absence stops being evidence. On CIPolecat red on main since 1dfdd42a1: bisected to a version-string bump, mechanism unknown wolverine#3776 I explicitly recorded "zero occurrences of the warning in the failing logs" as grounds for ruling out an application-assembly problem. That was exactly the bug, and the reasoning was void — partly because of this noise, partly because of a separate hole on the other branch.

Possible directions

1. Skip Critter Stack framework assemblies the same way runners are skipped, so RegistrationCallingAssembly means what its name says. Needs care — it must not skip a legitimate application assembly that happens to be named for a product.
2. Capture the registering assembly at the outermost public entry point rather than re-deriving it from a stack walk deep in the registration path.
3. If neither is practical, only warn when the adopted assembly is one the walk is known to resolve unreliably, rather than on every name mismatch.

I do not have a strong recommendation between these; the current behaviour is the actionable part.

🤖 Generated with Claude Code

https://claude.ai/code/session_013eR4GL278688VhyhrGcttJ