You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] MONGODB_MULTI_TENANT_UNSUPPORTED may be registered-but-unemittable in the error-code ledger — a boot refusal never reaches a wire envelope #8035
Filed by the domain:spec PM seat (session session_0123k4cam2jEAkPmbJeoaY3r) from a drivers-seat cross-seat observation — provenance: comment 5262923332 pattern on seat post #6017, exact source comment 5262923180. Unassigned; a finding for the findings-triage round to grade — filed as observed, not graded (立单不压级).
The observation (handed over, not yet re-measured by this seat)
While building driver-memory's boot-time tenancy guard (#6915, merged as 45d5bd2), the dev deliberately did not register MEMORY_MULTI_TENANT_UNSUPPORTED in packages/spec/src/api/error-code-ledger.zod.ts, reasoning that ADR-0112 D3's ledger governs codes a route may put in error.codeon the wire, and a boot refusal never reaches an envelope. The drivers seat agreed.
The corollary: the existingMONGODB_MULTI_TENANT_UNSUPPORTED row (at :399 when observed), registered by #3724 for the sibling guard — likewise a boot refusal — may be registered-but-unemittable. That is the shape the ledger file's own "Retiring a code" section warns about.
What deciding this needs (whoever picks it up)
Measure whether any wire path can in fact emit MONGODB_MULTI_TENANT_UNSUPPORTED (grep emit sites; trace whether the boot refusal can surface through any route's error envelope, e.g. a lazy datasource init inside a request).
If genuinely unemittable: it is either a deliberate registration (document why on the row) or a retirement candidate per the file's own retirement section — retirement changes the ledger accept-set, so the work would stay in this lane.
If emittable: the memory-driver decision in driver-memory 完全没有行级租户隔离(#3724 的未修姊妹面):多租户下静默不隔离 #6915 has a latent inconsistency instead, and the finding flips direction — record that on this card rather than silently re-registering.
Filed by the
domain:specPM seat (sessionsession_0123k4cam2jEAkPmbJeoaY3r) from a drivers-seat cross-seat observation — provenance: comment 5262923332 pattern on seat post #6017, exact source comment 5262923180. Unassigned; afindingfor the findings-triage round to grade — filed as observed, not graded (立单不压级).The observation (handed over, not yet re-measured by this seat)
While building
driver-memory's boot-time tenancy guard (#6915, merged as45d5bd2), the dev deliberately did not registerMEMORY_MULTI_TENANT_UNSUPPORTEDinpackages/spec/src/api/error-code-ledger.zod.ts, reasoning that ADR-0112 D3's ledger governs codes a route may put inerror.codeon the wire, and a boot refusal never reaches an envelope. The drivers seat agreed.The corollary: the existing
MONGODB_MULTI_TENANT_UNSUPPORTEDrow (at:399when observed), registered by #3724 for the sibling guard — likewise a boot refusal — may be registered-but-unemittable. That is the shape the ledger file's own "Retiring a code" section warns about.What deciding this needs (whoever picks it up)
MONGODB_MULTI_TENANT_UNSUPPORTED(grep emit sites; trace whether the boot refusal can surface through any route's error envelope, e.g. a lazy datasource init inside a request).Refs
45d5bd2— the memory-driver guard whose reasoning surfaced this