Portal reads hub posts GetDataRequest to Google data source without an AccessContext, dropping user identity #5431

What is failing

A GetDataRequest targeting the Google data source was posted to hub portal/reads/aoaPK0deOk2wEfqdiofxqw with no AccessContext — neither a Context nor a CircuitContext was attached. The framework's post pipeline treats this as a hard violation ("no identity, no delivery"), so the post lost the requesting user's identity and was not delivered. The user-facing effect is that whatever triggered this read (a portal reads view backed by the Google data source) silently gets no data.

Probable cause

Medium confidence. A caller in the portal/reads path posts to the hub without wiring an access context, instead of using one of the sanctioned sources: the circuit/HTTP user context, AccessService.ImpersonateAsSystem / PostOptions.ImpersonateAsHub for infrastructure work, or AccessContextScope.FromNode for thread/activity-initiated posts. This looks like a background or agent-initiated read that bypasses the ambient context plumbing rather than an end-user HTTP request (those carry the circuit context automatically). The exact caller cannot be named from the evidence: the burst carried no exception and no stack frame, so only the framework-side validator log is available. Note also the message text itself embeds the remedy checklist, suggesting this log site is a guard that fires when a new caller is wired incorrectly — see AccessContextPropagation.md and the feedback_access_context_always_set guidance referenced in the log.

Impact

Single occurrence so far (first seen 2026-09-23T01:57Z) on one portal pod, so the immediate user impact is one dropped read. However, this is a systemic guard: several sibling incidents at the same log site were opened in the admin partition within the same hour (e.g. d67b48fe47ffcb8d, f274f4eb8ad86996, d289b033ae135a72, 1d2082bcc900694d, 8ccad4e7c0a9a77e), which suggests this may be a wider pattern of context-unwired posts worth investigating together rather than as isolated one-offs. If any of these posts were delivered without identity, it would also be a security concern; the log wording indicates delivery is refused, which limits the blast radius to dropped requests.

Where to look

• Start from the MeshWeaver.AccessContext post-pipeline validator that emits this message — it validates posts into hub portal/reads/* and names the three sanctioned context sources.
• The concrete case: hub portal/reads/aoaPK0deOk2wEfqdiofxqw, message GetDataRequest, target Google — find which component subscribes/posts reads from the Google data source without an ambient context.
• Framework docs: AccessContextPropagation.md and the feedback_access_context_always_set feedback rule.

Evidence

2026-09-23 01:57:22Z 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=Google 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/9d444cbf18356216. Recurrences are folded into this issue rather than opening new ones.}