Portal reads hub posts GetDataRequest with no AccessContext — Mail read for a circuit fails closed #5435

What is failing

A per-circuit portal reads hub (portal/reads-…) posted a GetDataRequest targeting the Mail partition with no AccessContext — neither AccessService.Context nor CircuitContext was set. Per the never-null invariant, UserServicePostPipeline correctly failed the delivery and logged the tripwire, which means that circuit's Mail data request never completed (an awaiting hub.Observe(...) got an OnError). The failure mode itself is working as designed; the defect is that a user-facing portal hub reached the post with no resolvable identity.

Probable cause — medium confidence

The portal hub is the documented worked example for carrying the circuit user: ICircuitContextAccessor.UserContext feeds a per-hub PostPipeline step that stamps the circuit user when a post has no ambient context. For this post, both the ambient AsyncLocal and the CircuitContext accessor came back empty. The likely seam is a post originating off the circuit activity path — e.g. from a watcher/subscription emission, a background read refresh, or after circuit teardown — where CircuitContext is either not set for that hub instance or was cleared, and the fallback stamp step had nothing to stamp. Alternatively, the post site is genuinely infrastructure (a reads-hub-internal cache/warm-up) and should be declaring its identity (ImpersonateAsSystem / WithAccessContext) or be exempt ([SystemMessage]) rather than riding the User-mode default. Per AccessContextPropagation.md, every occurrence of this error is either a missing wrap (fix it) or a message that should be exempt — with one occurrence so far the evidence does not distinguish which, hence medium confidence.

Impact

Single occurrence on a single portal pod at one point in time. One user's Mail read for one circuit failed closed — a user-visible failure of that request, but no outage, no data corruption, and importantly no security exposure: the fail-closed behavior is the designed defense and it held. Watch for recurrence; if this fingerprint fans out across pods it graduates.

Where to look

Start at the portal reads hub's PostPipeline circuit-user stamp step (ICircuitContextAccessor.UserContext → the per-hub stamp when a post has no ambient context, per PortalApplication → CreatePortalAddress(circuitId)) and at what posts GetDataRequest with target Mail from portal/reads-* hubs. Reference: AccessContextPropagation.md — the invariant, the exempt list, and the anti-patterns table; memory feedback_access_context_always_set; tests PostPipelineAccessContextTest, AccessContextNeverNullTest.

Evidence

2026-09-23 02:28:18Z memex-portal-deployment-c54d5847c-m9crd fail: MeshWeaver.AccessContext[0]
      PostPipeline: AccessContext must never be null for an application post — no identity, no delivery. hub=portal/reads-aoaPK0deOk2wEfqdiofxqw, message=GetDataRequest, target=Mail was posted with no AccessContext (no Context, no CircuitContext). The post lost the user identity. Wire its source: user-context from the circuit/HTTP user; infrastructure via AccessService.ImpersonateAsSystem / PostOptions.ImpersonateAsHub; threads/activities via AccessContextScope.FromNode. See AccessContextPropagation.md / feedback_access_context_always_set.

_{Re-addressed by the current identity function: this incident inherited d67b48fe47ffcb8d (Systemorph/MeshWeaver.Plugins#1796). Those nodes are superseded and will not fold, file or comment again.}

_{Opened automatically from Admin/_LogIncident/4a90be793867ac0c. Recurrences are folded into this issue rather than opening new ones.}