Mail.MicrosoftGraph's IMeshQueryProvider (registration #36, Proxy route, generation #11) fails to construct — resolve reports a circular dependency on IMeshQueryProvider

Start with registration #36 and the IMeshQueryProvider implementation in MeshWeaver.Mail.MicrosoftGraph, then trace its constructor dependencies and compare the module resolve path in ModuleServices.cs with the fallback behavior in MeshServiceProvider.cs. Probe whether a later lease serves a mail query, and test root resolution with only this module installed against another provider module. Done means identifying which path creates the cycle and confirming whether it reproduces.

Observed

On pod memex-portal-deployment-848fd7f957-7bmzn (namespace memex-cloud), constructing registration #36 — IMeshQueryProvider, route Proxy — of module MeshWeaver.Mail.MicrosoftGraph, generation module:MeshWeaver.Mail.MicrosoftGraph#11, threw System.InvalidOperationException: A circular dependency was detected for the service of type 'MeshWeaver.Mesh.Services.IMeshQueryProvider': building it asked for itself again.

The resolve path (from the sample's stack): ModuleServices.Resolve(IServiceProvider root, Int32 index, MeshServiceProvider caller) (MeshWeaver.Mesh.Contract/ModuleServices.cs) → MeshServiceProvider.GetRequiredKeyedService → Resolve → Activate → Shared (MeshWeaver.ServiceProvider/MeshServiceProvider.cs, lines 188/425/515/567 of the running build). This is the leased resolve a query fan-out performs for a module's provider (ModuleContexts.TryLeaseModuleService), so the trigger was a query whose fan-out leased this module's IMeshQueryProvider.

Because the route is Proxy (a platform interface), the module's container falls back to the root for anything the registration's construction asks that the module does not declare; the cycle is that building the registration asked for IMeshQueryProvider — the very interface the registration produces — again. Whether the re-ask came from the provider's own constructor graph (a constructor or factory dependency that resolves to IMeshQueryProvider), or from the fallback/forwarding topology itself, is not established — see candidates below.

Where and when

A single occurrence on a single pod, at 00:58:01Z, on generation #11 of the mail module. One variant, one shape. Whether it coincided with a module landing, a live swap, or a plain runtime query is not recorded on the incident; the log line itself carries no trigger context.

Impact

The mail module's IMeshQueryProvider contribution did not serve for that use. The #6847 isolation (see Where to look) is designed so a registration that cannot be produced costs that module's feature, never the caller — so the expected user-visible effect is limited to whatever queries that provider serves (Microsoft Graph mail nodes), not sign-in or unrelated queries. But note the line's own classification: it says "nothing is recorded, the next use resolves it afresh" — this is a per-lease construction fault, not a durable ModuleServices.Unservable verdict. If the cycle is deterministic (a true registration-graph cycle, which a circular dependency usually is), every later lease re-attempts, fails the same way, and serves nothing — with only this one log line, ModuleServiceProxy.Serves still true, and /health silent (unservable-by-fault registrations are not listed there). The failure would then be invisible everywhere except this line. Whether that is the case here is the first thing to establish.

Not established

• Whether the fault reproduces on a later resolve of the same registration (the log is once per registration and exception type, so no further line is expected either way; absence of a second line is not evidence of recovery).
• Whether other pods or other registrations of the same module show the same fault (one pod, one registration, one occurrence in the window).
• Whether the fault is specific to generation #11 or would appear on any generation of MeshWeaver.Mail.MicrosoftGraph (i.e. whether it lives in the module's registration code or in this generation's layout).
• What triggered the lease at 00:58Z — which query, and whether a swap or landing preceded it.

Candidate causes and the reading that separates them

1. A cycle in the provider's own constructor graph. The registration's construction (constructor or factory) takes something that resolves to MeshWeaver.Mesh.Services.IMeshQueryProvider — directly, or via a root service whose stand-in is the module's own forwarded registration. Predicts: deterministic for this generation; a fresh boot of the same generation reproduces it; a NEW generation with a changed registration list does not. Discriminating reading: the constructor graph of registration #36 in MeshWeaver.Mail.MicrosoftGraph (which type implements its IMeshQueryProvider, and what that type's constructors ask for) — read in the module's source; plus whether the provider answers any query on that pod (a query its provider serves, run twice).
2. A self-referential fallback/forwarding topology for this interface. The module's container, asked for the platform interface, falls back to the root; the root's answer for IMeshQueryProvider is the module's own forwarder, which resolves index #36 back in the module — the loop is in the routing, not the module's code. Predicts: the same failure for ANY registration of a platform interface that this module is the only one to provide, on any generation, and a direct resolve of the interface off the root container fails identically. Discriminating reading: resolve IMeshQueryProvider directly off the root of a test mesh with only Mail.MicrosoftGraph installed; and compare with another module that registers IMeshQueryProvider (e.g. WhatsApp's provider, WhatsAppChatQueryProvider, referenced in the #6847 chain) — if only this module cycles, the module's graph is the likelier site.
3. A one-off, state-dependent construction fault (a caller-scope or lease re-entrancy that built the instance twice on one thread). Predicts: intermittent; the next lease succeeds and the provider serves. Discriminating reading: whether the module's provider answers a later query on that pod. This is the cheapest first reading, but it cannot be taken from the log alone — it needs a live probe (a query the provider serves, or a governed Logs action looking for the mail module's query behaviour after 00:58Z).

There is precedent for this exact exception shape inside a module container: the first draft of the ModuleInstanceOwners diagnostics resolved the registry through the resolve context, the module's fallback carried it into RootResolutionScope, and the container reported a circular dependency on the first module service resolved (see Ownership diagnostics in Doc/Architecture/LiveModuleUpdate). That instance was fixed by capturing the registry at build time; it is not this fault, but it shows a fallback stand-in can close a loop exactly this way.

Where to look

• MeshWeaver.ServiceProvider/MeshServiceProvider.cs — Shared (line 567), Activate (515), Resolve (425), GetRequiredKeyedService (188) in the running build: where the cycle was detected.
• MeshWeaver.Mesh.Contract/ModuleServices.cs — ModuleServices.Resolve(IServiceProvider root, Int32 index, MeshServiceProvider caller): the leased entry point, and the registration-index addressing (index #36 of Mail.MicrosoftGraph).
• ModuleContexts.TryLeaseModuleService (MeshWeaver.Mesh): the leasing classify/report path that produced this log line; the split between a per-lease fault (this line, nothing recorded) and a durable ModuleServices.Unservable verdict lives here.
• MeshWeaver.Mail.MicrosoftGraph, generation module:MeshWeaver.Mail.MicrosoftGraph#11, registration #36: the module's own IMeshQueryProvider registration and its constructor graph.
• Doc/Architecture/LiveModuleUpdate — section An optional module that cannot serve a service costs that feature — never sign-in (MeshWeaver#6847): the design of this log line, and the isolation that should keep this fault local to the mail feature.

Evidence

2026-10-26 00:58:01Z memex-portal-deployment-848fd7f957-7bmzn fail: MeshWeaver.Mesh.ModuleContexts[0]
      [MeshWeaver.Mesh.UnservableModuleService] registration #36 (IMeshQueryProvider, route Proxy) of module MeshWeaver.Mail.MicrosoftGraph (generation 'module:MeshWeaver.Mail.MicrosoftGraph#11') could not be constructed for the root: InvalidOperationException: A circular dependency was detected for the service of type 'MeshWeaver.Mesh.Services.IMeshQueryProvider': building it asked for itself again.. Only this use goes without the module's feature; nothing is recorded, the next use resolves it afresh. Reported once per registration and exception type.
      System.InvalidOperationException: A circular dependency was detected for the service of type 'MeshWeaver.Mesh.Services.IMeshQueryProvider': building it asked for itself again.
         at MeshWeaver.ServiceProvider.MeshServiceProvider.Shared(InstanceSlot slot, ServiceRegistration registration, ServiceIdentifier id, ResolveContext context) in /home/runner/work/MeshWeaver/MeshWeaver/src/MeshWeaver.ServiceProvider/MeshServiceProvider.cs:line 567
         at MeshWeaver.ServiceProvider.MeshServiceProvider.Activate(ServiceRegistration registration, MeshServiceProvider owner, ServiceIdentifier id, ResolveContext context) in /home/runner/work/MeshWeaver/MeshWeaver/src/MeshWeaver.ServiceProvider/MeshServiceProvider.cs:line 515
         at MeshWeaver.ServiceProvider.MeshServiceProvider.Resolve(ServiceIdentifier id, Boolean required, ResolveContext context) in /home/runner/work/MeshWeaver/MeshWeaver/src/MeshWeaver.ServiceProvider/MeshServiceProvider.cs:line 425
         at MeshWeaver.ServiceProvider.MeshServiceProvider.GetRequiredKeyedService(Type serviceType, Object serviceKey) in /home/runner/work/MeshWeaver/MeshWeaver/src/MeshWeaver.ServiceProvider/MeshServiceProvider.cs:line 188
         at MeshWeaver.Mesh.ModuleServices.Resolve(IServiceProvider root, Int32 index, MeshServiceProvider caller) in /home/runner/work/MeshWeaver/MeshWeaver/src/MeshWeaver.Mesh.Contract/ModuleServices.cs…[truncated]

_{Opened automatically from Admin/_LogIncident/c39f516d88ea8b08. Recurrences are folded into this issue rather than opening new ones.
It also stands for the whole log site 69a1dab1bc0a434b: other fingerprints of this site fold in here as comments rather than opening tickets of their own.}