reserveScript reads the record keys of the binding set's members, which it
cannot declare in KEYS, and its declared keys hash to different slots, so
Redis Cluster refuses it and a key-pattern ACL must allow the whole
<prefix>mcp: range. The script's comment, the pier README's
mcp.sessions.store row (which also no longer says the store opens on the
first request) and docs/services/mcp.md say so.
lazyStore's and newStore's doc comments no longer claim that nothing dials
at mount: Mount starts a background warm-up that dials Redis with a backoff
and logs each failed attempt. The comment records the decision to keep the
warm-up for commands that mount pier without serving, such as route:list:
it only dials and logs until the process exits.
- Identity.fingerprint covers scopes, both subjects, the ceiling and the
token kind; a stateful lookup or stateless hit whose fingerprint changed
re-filters the server with the event diff under its own mutex (A-WR-04)
- Mount warms a Redis store in the background with a 1 s to 30 s backoff
and every request kicks a pending open without waiting, so stateless-only
instances subscribe to fan-out (A-WR-05)
- a stateless subscriptions/listen POST re-verifies its bearer every
recheck interval; an LRU-evicted stateless server closes its sessions
(A-WR-06)
- resolvePersonalToken refuses a subject with TokenID 0, and the
pact.MCPPersonalTokenResolver contract says one resolver per application,
false means unauthorized and TokenID keys the binding (A-WR-09, A-IN-03)
- an unexported reserver (Reserve, Release) next to updater: the memory
store reserves under its mutex, the Redis store in one Lua script
(prune, SCARD, SET PX plus SADD); serveNew reserves instead of Count
then Put and releases on a failed connect or initialize (A-WR-03)
- serveNew, lookup's rehydration and the stateless getServer build the
SDK server with no router-wide lock held and insert or adopt under the
lock afterwards, so a slow guard or database check no longer stalls
the instance (A-WR-07)
- persisting a session's protocol state after a request now rewrites an
existing record only (Redis SET XX, the memory store likewise) and closes
the local copy when the record is gone
- before, a request that finished after DELETE, a revoked or deleted subject
event or the idle expiry put the record back, and the next request
rehydrated the ended session
- found by plan 19.7-05's TestFanOut (revocation and deletion cases, about
one run in a hundred)
- store_redis.go: records with PX TTLs, per-binding sets, pub/sub events,
opened lazily from redis.url under cooler's prefix (nothing dials at mount)
- events.go: pact.MCPSubjectChanged republished through the store; every
instance recomputes the subject's sessions and stateless servers
(list_changed) or ends them on revocation; the link cache is dropped
- stateless.go: the SDK's stateless handler over per-identity servers for
2026-07-28 clients, routed by the protocol header or server/discover
- prm.go: RFC 9728 metadata at both well-known paths; long GET streams
re-verify their bearer every minute
- TestPierSessionsSmoke, TestPierFanOutSmoke, TestPierStatelessSmoke on
miniredis; README features, configuration and operational notes
