RememberedApplicationAssembly (process-wide static) silently pins handler discovery for every later implicit host — order-dependent test failures with no loud signal

[jeremydmiller]

Wolverine 6.21.0 (behavior also present in 6.20 and mirrored in JasperFx's JasperFxOptions). Not a regression — a diagnosability/documentation gap that cost a full debugging session in CritterWatch (JasperFx/CritterWatch@b365a48e has the war story).

The trap

WolverineOptions.RememberedApplicationAssembly (and JasperFx's twin) is a process-wide static: the first host that falls through to determineCallingAssembly() pins the application assembly for every later host in the process that doesn't set one explicitly. In a normal app that's one host and the cache is harmless. In a test assembly that builds many hosts (xunit/vstest process), it means:

• whichever test class runs FIRST decides handler discovery's scanned assembly for every subsequent implicit host;
• conventional handlers defined in the test assembly silently vanish for the whole run when an earlier host resolved to a referenced assembly instead (Tests.Common, the app-under-test's assembly, …);
• the visible symptom is downstream and quiet — No routes can be determined for Envelope … (SomeMessage) at info level, null scatter/gather results;
• and it's order-dependent: tests pass filtered/in isolation, fail in full-suite runs, and can flip between builds because test-order changes with recompilation. Ours initially looked exactly like a package-bump regression.

Asks (any subset)

1. Log the pinning loudly: when establishApplicationAssembly serves RememberedApplicationAssembly to a host whose calling assembly would have resolved differently, log a warning naming both assemblies ("application assembly X reused from a previous host in this process; handler discovery will NOT scan Y — set opts.ApplicationAssembly or opts.Discovery.IncludeAssembly to override").
2. Document the static in the testing docs (parallel/serial multi-host test processes) with the opts.Discovery.IncludeAssembly(...) / explicit opts.ApplicationAssembly remedies — the troubleshooting docs cover discovery generally but not the first-host-wins static.
3. Consider scoping the cache (e.g., keying by calling assembly) or an opt-out for test processes.

The wolverine-troubleshooting-message-routing AI skill's IncludeAssembly guidance is what led us to the fix; the test-parallelization skill would be a natural home for a warning about this static too.

[jeremydmiller]

Follow-up filed: the JasperFx JasperFxOptions twin — the dominant process-wide static that #3530 flagged — now gets the same divergence detection in JasperFx/jasperfx#543. That surfaces the diagnostic for non-Wolverine hosts (Marten, etc.); Wolverine hosts were already covered by #3530. Detection-only, exposed as a public ApplicationAssemblyReuseWarning property (JasperFx is a library with no always-on startup service, so consumers emit it). Once that ships + the pin bumps, asks 1 & 2 are complete across the stack; ask 3 (changing caching semantics) remains intentionally out of scope.

[jeremydmiller]

Ask 1 shipped today in #4024 (bc9bea9e3); asks 2 and 3 did not. Recording which is which so this issue reflects what is actually left.

Ask 1 — "log the pinning loudly" — done

when establishApplicationAssembly serves RememberedApplicationAssembly to a host whose calling assembly would have resolved differently, log a warning naming both assemblies

That branch previously adopted the process-wide pin in silence — only the jasperfx.ApplicationAssembly path called CheckForDivergentApplicationAssembly, so the one path this issue is actually about could never warn. It now checks, matching what JasperFxOptions already did from its equivalent branch.

Worth stating plainly: the warning shipped in #3530 was not usable until today. Instrumenting a fully green CoreTests run found it firing 44 times, and none of those were real:

"registered from"	count
runtime-compiled assemblies (ofqrxydn.tlz, …)	41
JasperFx	5
a real application assembly	1

Those random names are Roslyn's Path.GetRandomFileName() — Wolverine's own generated code, with a different name on every run. #4024 fixed that (and the fact that RegistrationCallingAssembly was resolving to whoever called Build() rather than whoever called UseWolverine()). Same suite, after: 1 warning, and it is a true positive.

So the diagnostic this issue asked for now exists and can be reasoned from in both directions, which is the part that matters — the earlier version could not be, and that misled the #3776 investigation.

Ask 2 — document the static — NOT done

grep -rln RememberedApplicationAssembly docs/ returns nothing. The first-host-wins static is still undocumented in the testing docs, along with the opts.Discovery.IncludeAssembly(...) / explicit opts.ApplicationAssembly remedies. This is the ask most likely to have saved the CritterWatch session, and it is untouched.

Ask 3 — scope the cache or offer an opt-out — NOT done

Still first-host-wins, process-wide.

Suggest narrowing the title/scope to asks 2 and 3.

[jeremydmiller]

Correction to my earlier comment: I was wrong that ask 2 was not done.

I based that on grep -rln RememberedApplicationAssembly docs/ returning nothing. The docs do cover this — they simply never name the identifier. Both blocks landed with #3530, the original warning PR:

• docs/guide/handlers/discovery.md, under Assembly Discovery — the process-wide cache, the multi-host test-process case, the order-dependence, the quiet No routes can be determined symptom, and both remedies.
• docs/guide/testing.md, in the introduction — a pointer to it, naming opts.ApplicationAssembly and opts.Discovery.IncludeAssembly(...).

That covers ask 2 in both of the places this issue asked for it. Apologies for sending anyone looking for work that already exists.

The one genuine gap was the identifier itself — zero occurrences in the docs, so meeting RememberedApplicationAssembly in IntelliSense or a stack trace and searching the documentation turned up nothing. #4034 names it and its JasperFxOptions twin.

#4034 also corrects something the block was asserting that was not true until yesterday: "Wolverine now logs a warning at startup when a host adopts an application assembly that differs from where it was registered." Until GH-3778, establishApplicationAssembly adopted RememberedApplicationAssembly without calling the divergence check — so the process-wide pin, the whole subject of that warning block, was precisely the path that could not warn. A reader on an older release could have taken silence as evidence they did not have the problem.

So the remaining scope on this issue is ask 3 alone — scoping the cache or offering an opt-out.

[jeremydmiller]

Parking ask 3 (scope the cache / opt-out) until JasperFx 2.55.

The static this issue is about has a twin one level down — JasperFxOptions.RememberedApplicationAssembly — and the two are read by the same resolution path. Scoping or opting out of Wolverine's copy alone would leave the JasperFx one still pinning process-wide, so the behaviour would only half-change and the remedy documented under Assembly Discovery would become harder to describe, not easier.

JasperFx/jasperfx#697 is the upstream work. Whatever shape the cache takes there is the shape this should follow, so this waits for 2.55 rather than diverging.

Asks 1 and 2 are done — the warning (#4024) and the docs (#4034).