Fence shared session caches with authorization generations
Extend fencing guidance with network authority separation and a concrete bounded-warning example when sharing workers fail.
Fence shared session caches with authorization generations
Trigger
Use when one process serves multiple root and child sessions, caches context for later message transformation, and may outlive authorization replacement or revocation.
Failure prevented
A process-global or session-only cache can inject another session's context. More subtly, stale context can survive authorization replacement and appear to authorize queued network work. Deleting cache entries does not close the race when a worker already holds a snapshot or revocation occurs between a local check and request transmission.
Practical steps
- Key every immutable entry by trusted root identity, child binding identity, authorization identity, and a nonreused authorization generation. Require exact lookup; never fall back to a latest, root-only, or neighboring entry.
- Give each child an immutable sanitized snapshot and binding identity. On authorization replacement, recreate or explicitly rebind it with a new binding identity; never silently upgrade it.
- Make replacement a linearizable authoritative transition. First make the old generation unusable, then establish the new generation. Cancel queued network work stamped with the old generation before new entries are written.
- Separate prompt authority from network authority. The system-message transform may read only generation-matched cache entries. Outbound sharing or sync calls must carry a transmit token minted by the live authorization handle for the same generation observed at send time. A stale cache hit must never mint or reuse a transmit token.
- On replacement, tombstone the old generation, purge its cache bucket, and reject in-flight workers whose captured generation differs from the live handle.
Bounded warning-cardinality when sharing stays denied
Rule example: per root session and authorization generation, emit at most one user-visible warning card per denial reason code (for example sharingworkertimeout, sharingworkercrash, generation_mismatch). Further failures increment an internal counter only; surface a single aggregated follow-up card when the counter crosses a fixed threshold such as five, never unbounded distinct cards.
Run the sharing validation and transmit step in an isolated worker subprocess that alone holds the transmit capability. If the worker hits a deadline or crashes, the primary task continues locally without sharing. Sharing remains denied because no valid transmit token is returned; the host records one cardinality-bounded warning and does not retry with stale cached context as authority.
Verification mindset
Property-test generation flips under concurrent cache writes and queued sends. Integration-test worker timeout and crash paths: primary completes, sharing API never called, warning count stays within the cardinality cap.