Found while implementing #12928 (sys_upload_session forward org-stamp). ⛔ Deliberately NOT fixed there: #12928 is scoped by a maintainer ruling to one insert in service-storage, and this is the class-level mechanism one layer down. Recorded so the asymmetry is visible.
The #12928 triage comment listed this as its second unmeasured confidence gap — "I did not measure why the unscoped-write alarm did not fire for this insert" — and said that if the mechanism should have covered the insert and did not, the real repair for the whole class lives there. It is measured here.
Measured, on origin/main at 1a540e8
1. The mechanism DOES cover the insert. SqlDriver.create calls it:
packages/drivers/driver-sql/src/sql-driver.ts:5711 this.auditMissingTenant(object, 'create', options);
and seven sibling verbs do the same (update, upsert, delete, bulkCreate, bulkDelete, updateMany, deleteMany). So the answer to "why did it not fire" is not "the door is not wired".
2. It is a logger.warn, and nothing more. auditMissingTenant (same file, near line 11948) emits one line and returns. No throw, no counter, no report, no gate. Nothing in the tree can assert on it having fired for a given production door.
3. It is off in every environment where the code is actually exercised. Three early-outs, in order:
if (process.env.OS_TENANT_AUDIT === '0') return;
if (options?.bypassTenantAudit === true) return;
...
if (!this.isMultiTenantMode()) return; // postureEnforcesWall(resolveTenancyPosture())
isMultiTenantMode() is false under the single posture — the default, and what unit tests, dev boots and the dogfood stack run on. So the signal exists only on a walled production deployment, and only as one log line.
4. Throttled to once per process. this.tenantAuditWarned.add(key) keys on object:op, so the warning for sys_upload_session:create appears once per process lifetime regardless of how many unstamped rows are written after it.
Why this is the class-level defect
Two tenancy-enabled objects in one service shipped with an insert that carried no context — sys_file (fixed in #12745) and sys_upload_session (fixed in #12928) — and each was found by a human reading the call site, not by this control. That is the expected outcome of the four properties above: the one mechanism designed to catch exactly this shape produces no artifact that a test, a gate or a review can read.
Existing tests confirm the reading rather than contradict it. packages/drivers/driver-sql/src/sql-driver-tenant-audit-posture.test.ts asserts the warning fires on a posture-only walled deployment, and sql-driver-tenant-scope.test.ts:400 records that it "only fires in multi-tenant mode (single-tenant ...)". Both test the mechanism in isolation; neither asserts anything about a real service door.
Not established here
Re-check
git grep -n "auditMissingTenant(" -- packages/drivers/driver-sql/src/sql-driver.ts
git grep -n "isMultiTenantMode\|tenantAuditWarned" -- packages/drivers/driver-sql/src/sql-driver.ts
Dedup
Searched the tenant-audit / tenancy-stamping family. #10673 (updateMany on sys_http_delivery / sys_notification_delivery without options.tenantId) is a third per-table instance of the same class, closed — it does not cover the mechanism. #12745 and #12928 are the two service-storage instances. #9516, #8245 and #9451 are audit-row and seed-repair tenancy cards on other surfaces. No match for the mechanism-level card.
Found while implementing #12928 (
sys_upload_sessionforward org-stamp). ⛔ Deliberately NOT fixed there: #12928 is scoped by a maintainer ruling to one insert inservice-storage, and this is the class-level mechanism one layer down. Recorded so the asymmetry is visible.The #12928 triage comment listed this as its second unmeasured confidence gap — "I did not measure why the unscoped-write alarm did not fire for this insert" — and said that if the mechanism should have covered the insert and did not, the real repair for the whole class lives there. It is measured here.
Measured, on
origin/mainat1a540e81. The mechanism DOES cover the insert.
SqlDriver.createcalls it:and seven sibling verbs do the same (
update,upsert,delete,bulkCreate,bulkDelete,updateMany,deleteMany). So the answer to "why did it not fire" is not "the door is not wired".2. It is a
logger.warn, and nothing more.auditMissingTenant(same file, near line 11948) emits one line and returns. No throw, no counter, no report, no gate. Nothing in the tree can assert on it having fired for a given production door.3. It is off in every environment where the code is actually exercised. Three early-outs, in order:
isMultiTenantMode()isfalseunder thesingleposture — the default, and what unit tests, dev boots and the dogfood stack run on. So the signal exists only on a walled production deployment, and only as one log line.4. Throttled to once per process.
this.tenantAuditWarned.add(key)keys onobject:op, so the warning forsys_upload_session:createappears once per process lifetime regardless of how many unstamped rows are written after it.Why this is the class-level defect
Two tenancy-enabled objects in one service shipped with an insert that carried no context —
sys_file(fixed in #12745) andsys_upload_session(fixed in #12928) — and each was found by a human reading the call site, not by this control. That is the expected outcome of the four properties above: the one mechanism designed to catch exactly this shape produces no artifact that a test, a gate or a review can read.Existing tests confirm the reading rather than contradict it.
packages/drivers/driver-sql/src/sql-driver-tenant-audit-posture.test.tsasserts the warning fires on a posture-only walled deployment, andsql-driver-tenant-scope.test.ts:400records that it "only fires in multi-tenant mode (single-tenant ...)". Both test the mechanism in isolation; neither asserts anything about a real service door.Not established here
single-posture early-out is wrong. It exists because the kernel always provisionsorganization_id, so column presence alone stopped implying "tenant-scoped" and every system write would otherwise warn on a single-tenant boot. Removing that guard is not obviously the fix.applyTenantScope's NULL-as-global read semantics. That is Freshobjectstack devboot: tenant admin sees ZERO rows in sys_position / sys_permission_set / sys_business_unit over REST (Setup Access Control renders empty) #2734's deliberate fail-open and is out of scope here as it was in multi-org:sys_upload_sessionis never org-stamped either —StorageMetadataStore.createSessioninserts without a context #12928.Re-check
Dedup
Searched the tenant-audit / tenancy-stamping family. #10673 (
updateManyonsys_http_delivery/sys_notification_deliverywithoutoptions.tenantId) is a third per-table instance of the same class, closed — it does not cover the mechanism. #12745 and #12928 are the twoservice-storageinstances. #9516, #8245 and #9451 are audit-row and seed-repair tenancy cards on other surfaces. No match for the mechanism-level card.