[rbuergi]

Why

The fixes for #6584 and #6588 shipped, but neither defect wrote a log line while it was live. The production log readings on both issues (2026-10-21) were therefore inconclusive: a quiet log after the fix cannot tell "fixed" from "never logs". The owner's decision was to add the line each defect WOULD write, roll it, then verify on production.

Refs #6584
Refs #6588

What

Ownership diagnostics. Every line is a Warning under category MeshWeaver.ServiceProvider.ModuleScopeOwnership with the stable prefix [ModuleScopeOwnership], names its issue, and is written once per registration (so a live defect cannot flood Loki). The correct route writes nothing. No existing log level is changed.

• A module's scoped services are shared across every Blazor circuit and built against no circuit (Radzen ThemeService/DialogService) #6584, built for no caller. A middleware on every shared registration of a module container (ModuleServiceProvider.CreateForCallers → ModuleScopeDiagnostics) warns when a module's SCOPED registration is activated in the module container's own root scope. That is the defect's shape: one instance per generation, shared by every circuit and built against none.
• A module's scoped services are shared across every Blazor circuit and built against no circuit (Radzen ThemeService/DialogService) #6584, served across callers. ModuleServiceProvider.ReportIfServedAcrossCallers, called from ResolveAt(…, caller) and ModuleServices.Resolve(…, caller), warns when a scoped instance is handed to a caller that does not own the module scope it was built in.
• Module root forwarders own what they return: a circuit ending disposes a module singleton for every user #6588, disposed by a non-owner. PopulateMeshWeaver (every MeshWeaver container and hub scope) watches factory-activated registrations owned by the resolving scope. When one returns an instance a module owns, the warning is written as that scope begins to end, just before it disposes the instance.
• The ownership registry. ModuleInstanceOwners holds one entry per instance, weakly (ConditionalWeakTable, so it pins no generation). There is one per mesh, registered by MeshBuilder as an instance, never static. It records what each module container built, plus ModuleServiceProxy instances over disposable interfaces. The registry and its logger are captured when a container is built and never resolved mid-resolve. A first draft resolved them through the resolve context, and that recursed through RootResolutionScope into a circular dependency, which the existing ownership tests caught.

Tests

ModuleScopeOwnershipDiagnosticsTest re-introduces each defect deliberately and shows its line fires. These are the negative controls:

• the scoped registration resolved off the module container with no caller, the route before fix(modules): a module's scoped service is built in a module scope its caller owns (#6584) #6586;
• circuit A's instance handed to circuit B;
• owned root forwarders, the route before fix(modules): a module forwarder owns nothing it returns (#6588) #6591. The test asserts the singleton really was disposed and the scoped instance disposed twice, so the control is live.

The same suite shows the correct routes write nothing, on raw Autofac containers and through a full generic host with a module installed in its own load context.

Local: MeshWeaver.ServiceProvider, MeshWeaver.Mesh.Contract and MeshWeaver.Compiler.Pipeline.Test build with -c Release -warnaserror (0 warnings, 0 errors). The new suite and the existing ownership suites (AModuleForwarderOwnsNothing*, ANotOwnedForwarderKeepsItsPositionTest, AnotherModulesScopedServiceIsTheCallersTest, ACallersModuleScopeEndsWithTheGenerationTest, CallerAndModuleScopedServicesBuildInOneLockTest) pass: 18 of 18. The whole MeshWeaver.Compiler.Pipeline.Test project passes: 1566 of 1566.

Verification after the roll

The plan is posted on both issues. In short: governed Logs InstanceActions on the control MCP server, query |= "[ModuleScopeOwnership]", run against each portal. A zero counts only alongside two things in the same window and with the same selector:

1. evidence that the image carries this change;
2. a positive control ([ModuleLoad] lines of the same pods) proving the query reads that portal and was not cut.

No recycle is needed. The diagnostics live in the root and module containers, which a pod roll rebuilds.

Doc: Doc/Architecture/LiveModuleUpdate → "Ownership diagnostics: the line each defect would write".

Pairs-with: none — additive only; no public type or member removed.
Implementers: none — no interface member added.
Mirror-sync: none — no i18n catalog key added or changed.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Warning suppression and overwritten ownership records can hide the defects these diagnostics are intended to expose.

3 open issues

• Preserve the first disposal owner for aliased instances · New
• Claim reports at scope end using registration ID only · New
• Preserve the first recorded caller for shared factory instances · New

What changed in this PR

Adds module ownership diagnostics to make regressions behind #6584 and #6588 visible in production logs.

Changes:

• Tracks module-owned instances and warns about incorrect sharing or disposal.
• Connects diagnostics to containers, service resolution, and disposable proxies.
• Adds negative-control tests and production verification guidance.

File	Description
test/​MeshWeaver.Compiler.Pipeline.Test/​ModuleScopeOwnershipDiagnosticsTest.cs	Tests faulty and correct ownership routes.
src/​MeshWeaver.ServiceProvider/​ServiceProviderExtensions.cs	Shares ownership tracking across scopes.
src/​MeshWeaver.ServiceProvider/​NotOwnedServiceDescriptor.cs	Attaches disposal diagnostics during registration.
src/​MeshWeaver.ServiceProvider/​ModuleServiceProvider.cs	Tracks activation and cross-caller resolution.
src/​MeshWeaver.ServiceProvider/​ModuleScopeOwnership.cs	Implements ownership tracking and warnings.
src/​MeshWeaver.ServiceProvider/​MeshWeaver.ServiceProvider.csproj	Adds logging abstractions.
src/​MeshWeaver.Mesh.Contract/​ModuleServices.cs	Checks ownership when serving instances.
src/​MeshWeaver.Mesh.Contract/​ModuleServiceForwarders.cs	Records disposable proxy ownership.
src/​MeshWeaver.Mesh.Contract/​MeshBuilder.cs	Registers mesh-scoped ownership tracking.
src/​MeshWeaver.Documentation/​Data/​Architecture/​LiveModuleUpdate.md	Documents diagnostics and verification.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Diagnostic coverage gaps and registration deduplication can hide ownership failures from production verification.

3 open issues

• Record attempted scoped activations before construction · New
• Track disposable transients to prevent double disposal · New
• Key warnings by serving registration identity · New

3 resolved since last review

• Preserve the first recorded caller for shared factory instances
• Claim reports at scope end using registration ID only
• Preserve the first disposal owner for aliased instances

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The verification procedure can falsely declare success when an earlier warning falls outside the query window and later occurrences are suppressed.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Suppressed warnings can make zero-warning results falsely pass

src/​MeshWeaver.Documentation/​Data/​Architecture/​LiveModuleUpdate.md:538

A later exercise can produce zero warnings while the defect remains. Once a warning is reported, subsequent occurrences are suppressed; if that first warning predates the query window, the image and log controls above can both pass without exposing it. Require complete, untruncated log coverage from each relevant pod's process start through the exercise before treating zero as a closing reading. Otherwise, mark the result inconclusive.

3 resolved since last review

• Key warnings by serving registration identity
• Track disposable transients to prevent double disposal
• Record attempted scoped activations before construction

_{Review effort: Balanced}

[github-actions]

Test Results

    22 files      22 suites   1h 3m 49s ⏱️
13 604 tests 13 604 ✅ 0 💤 0 ❌
13 634 runs  13 634 ✅ 0 💤 0 ❌

Results for commit 9b9cafa.