Portal reads hub posts GetDataRequest to Stripe hub without AccessContext — request dropped by PostPipeline guard #5434

What is failing

The portal/reads-Ynxsv3qCj0--0Sc8PAt7oA hub posted a GetDataRequest targeting the Stripe hub with no AccessContext — neither an ambient Context nor a CircuitContext was attached. The MeshWeaver.AccessContext PostPipeline guard rejects such posts, so the request is dropped and the Stripe hub never receives it: the caller sees no data (or hangs on a response that never comes) with no identity attached for auditing.

Probable cause

A code path on the portal reads hub posts data requests outside the scope of an authenticated circuit / HTTP request, so no AccessContext is captured on the post. Per the log's own guidance the fix is one of: wire the user context from the circuit/HTTP user, or explicitly use AccessService.ImpersonateAsSystem / PostOptions.ImpersonateAsHub if this is infrastructure traffic.

Confidence: moderate. The missing piece (AccessContext on the post to Stripe) is unambiguous from the log, but the exact call site in the portal reads hub cannot be pinpointed from the mesh — no source or doc node for the MeshWeaver.AccessContext post pipeline or the portal reads hub was findable in the indexed partitions.

Impact

Minimal so far for this variant: 1 occurrence on one portal pod. However, this is the same defect class as incident fingerprint d67b48fe47ffcb8d (superseded by this one), which accumulated 2128 occurrences across 37 portal pods over ~3.5 weeks before being folded — the same guard, same symptom, different hub/target shapes (Hosting/PlatformBuilds, Event/* talk hubs, portal/nodeops-*). This ticket covers the new target=Stripe / GetDataRequest shape.

Duplicate / related

The parent fingerprint was already filed as #1253 ("nodeops hub posts GetDataRequest messages without AccessContext in PostPipeline", status Superseded). If that issue is still open, this is best handled as another instance of the same defect — wire the AccessContext source for posts originating on portal reads hubs — and can be closed as a duplicate once #1253 covers this shape.

Where to look

• The MeshWeaver.AccessContext post pipeline guard that emits PostPipeline: AccessContext must never be null for an application post.
• Callers on the portal reads hub (portal/reads-*) that post GetDataRequest messages to the Stripe hub — likely a background/cached read path not wrapped in an AccessContextScope or impersonation.
• Internal reference: AccessContextPropagation.md / feedback_access_context_always_set (not found in indexed mesh partitions).

Evidence

2026-09-23 02:19:11Z memex-portal-deployment-c54d5847c-t7cm2 fail: MeshWeaver.AccessContext[0]
      PostPipeline: AccessContext must never be null for an application post — no identity, no delivery. hub=portal/reads-Ynxsv3qCj0--0Sc8PAt7oA, message=GetDataRequest, target=Stripe 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/c37271e0dbf14e4f. Recurrences are folded into this issue rather than opening new ones.}