Filed unassigned from the domain:engine execution seat while landing #15225 (PR #15687). Observation class — a test comment that mis-describes why its pin passes; no runtime defect, no assertion is wrong.
What the comment says
packages/objectql/src/engine-data-events.test.ts, block #14970 — a published DataEvent names the RECORD's organization, pin an object that is not tenant-scoped OMITS the key on all three actions:
task declares no organization_id, so resolveTenantFieldName finds no column and nothing is published — rather than the caller's org being used as a stand-in
What is measured
Registering an object through engine.registry.registerObject INJECTS the kernel organization_id column (registry.ts, TENANT_SCOPE_FIELD_DEF, guarded only by the injection plan's tenant flag — i.e. unless the object declares tenancy: { enabled: false }). So on the registered task, resolveTenantFieldName answers organization_id, not null. The pin still passes — correctly — because eventOrganizationId reads the ROW's column and the row carries no organization. The sentence attributes the omission to the wrong cause.
Measured while writing #15225's bulk pins: a predicate write on the registered task under an isolated wall had the batch key stamped, precisely because the object IS tenant-scoped once registered; the security plugin walls on the same injected field set (getObjectFieldNames → objectHasOrgIdField). #15225's block therefore pins the genuinely unscoped case on a tenancy: { enabled: false } object and asserts the column was withheld before asserting omission.
Why it matters
The next author who copies this pin's reasoning builds a "not tenant-scoped" fixture out of an object that is walled — the mistake #15225 made once before measuring. The fix is a comment reword (the row carries no organization; the column exists) or switching the fixture to the declared opt-out with the measured assertion, as the sibling block now does.
Refs: #14970 (the block), #15225 / PR #15687 (where the divergence was measured). #14970 is not reopened by this; nothing here is a closing keyword.
Filed unassigned from the
domain:engineexecution seat while landing #15225 (PR #15687). Observation class — a test comment that mis-describes why its pin passes; no runtime defect, no assertion is wrong.What the comment says
packages/objectql/src/engine-data-events.test.ts, block#14970 — a published DataEvent names the RECORD's organization, pinan object that is not tenant-scoped OMITS the key on all three actions:What is measured
Registering an object through
engine.registry.registerObjectINJECTS the kernelorganization_idcolumn (registry.ts,TENANT_SCOPE_FIELD_DEF, guarded only by the injection plan'stenantflag — i.e. unless the object declarestenancy: { enabled: false }). So on the registeredtask,resolveTenantFieldNameanswersorganization_id, notnull. The pin still passes — correctly — becauseeventOrganizationIdreads the ROW's column and the row carries no organization. The sentence attributes the omission to the wrong cause.Measured while writing #15225's bulk pins: a predicate write on the registered
taskunder anisolatedwall had the batch key stamped, precisely because the object IS tenant-scoped once registered; the security plugin walls on the same injected field set (getObjectFieldNames→objectHasOrgIdField). #15225's block therefore pins the genuinely unscoped case on atenancy: { enabled: false }object and asserts the column was withheld before asserting omission.Why it matters
The next author who copies this pin's reasoning builds a "not tenant-scoped" fixture out of an object that is walled — the mistake #15225 made once before measuring. The fix is a comment reword (the row carries no organization; the column exists) or switching the fixture to the declared opt-out with the measured assertion, as the sibling block now does.
Refs: #14970 (the block), #15225 / PR #15687 (where the divergence was measured). #14970 is not reopened by this; nothing here is a closing keyword.