System-context writes land untenanted at RUNTIME, so a single-tenant install keeps re-forking the autonumber scope and minting duplicate business identifiers — the producer #8686's backfill cannot reach (17.0.0 GA)

[baozhoutao]

Direct residual of #8686 (closed COMPLETED 2026-08-15 by PR #8832). That card fixed one producer of untenanted rows — the seed loader — and shipped a one-shot backfill for rows it had already written. This card is about the other producer, which is still running: ordinary application writes made under a system execution context. A backfill cannot reach it, because it mints a new duplicate every time a hook, a scheduled job, a custom endpoint or a runAs: system flow creates a record.

Measured on @objectstack/* 17.0.0 GA in a real single-tenant app (an EHR/MES install, ~44 autonumbered objects), and code-confirmed against the shipped 17.0.0 artifacts.

Symptom

Same object, same install, Tenancy: single, two records with the same value on an autonumber business-key field, no error and no warning:

dispatch_order (the base table every dispatch category lands in):
 DEFAULTWI0020260811001002 <- rework order, created by a quality-verdict HOOK (sudo)
 DEFAULTWI0020260811001002 <- production order, created by a PLANNER in the Console

Searching by document number now returns 2 records; two record pages carry the same title.

Not object-specific. Observed duplicated on the same install: dispatch_order, inspection_request (report-for-inspection), notification, quality_dispatch_item, andon_record. The notification case is the crispest, because both producers are visible side by side — a cron job and a user action:

notification numbers on one fresh DB:
 NT-00002 .. NT-00011 each appears TWICE
 copy A: created by the "maintenance overdue" CRON job (system context)
 copy B: created by a user action / hook on a user request (session context)

Reproduced across two independent test rounds on fresh databases.

Mechanism

Identical in shape to #8686, one layer up: the autonumber scope is a function of whether the row got an organization_id stamped, and a system-context write does not get one.

_objectstack_sequences, one object, one scope key `DEFAULTWI0020260811001`:
 tenant_id = 'org_msokm9oaz0cal87q' last_value = 2 <- REST / Console writes
 tenant_id = '__global__' last_value = 2 <- system-context writes

The two rows cannot see each other, so each is correct within its own scope and both hand out 002.

Confirmed in the shipped 17.0.0 @objectstack/driver-sql artifact:

• GLOBAL_TENANT = "__global__", and the tenant-column key is materialized as COALESCE(<tenantField>, '__global__');
• fillAutoNumberFields() derives the sequence tenant as row[cfg.tenantField] ?? options.tenantId ?? null — i.e. read off the row, after stamping;
• getNextSequenceValue() and resyncSequenceToDataMax() both collapse a null tenant to GLOBAL_TENANT.

So the defect is upstream of the counter — exactly the boundary #8686's triage drew, and the reason "make the counter smarter" was ruled out there. Both counters are already correct.

The upstream half is the write context. #8672 measured the same primitive directly, on a different object: insert under { isSystem: true } stores organization_id NULL. That card filed it as an observation about sys_permission_set, where an org-less row is arguably correct by design. On application objects it is not arguable — it silently forks the uniqueness partition of a field the app declared unique.

Why #8686's fix does not cover this

PR #8832 touches packages/metadata-protocol/src/migrations/seed-tenancy-backfill.ts, packages/metadata-protocol/src/plugin.ts and packages/runtime/src/app-plugin.ts — the seed-apply path plus a one-shot repair. Nothing in that diff changes how a runtime write under a system context resolves its organization. After the fix:

• seed rows are stamped and the historical split is merged → good;
• the very next hook/cron/endpoint write still lands organization_id = NULL, re-creates the __global__ sequence row, and the split reopens.

The backfill is therefore self-undoing on any install that has server-side automation, which is the normal case for a business app.

⚠️ The obvious app-side remedy is worse, and was measured

Adding a unique index on the number field escalates this from a silent duplicate to a hard create failure. The collision self-heal rescans for the max existing value, but the rescan is org-filtered too — it cannot see the other partition, re-mints the identical number, and exhausts its retries. Measured on the reporting install; do not recommend it as a workaround.

What a fix has to decide

The same question #8686 answered for the seed path, answered once more for the runtime path:

1. A system-context write on a tenant-scoped object resolves the install's organization the way a session write does (the twin of Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686's ruling — on a single-tenant install this is derivable; on multi-tenant it is not, and the write must either carry an explicit organization or be refused rather than silently defaulting to __global__).
2. Or system-context writes are deliberately untenanted, in which case the autonumber scope and the COALESCE(..., '__global__') unique partition must stop treating the pseudo-tenant as a peer of a real organization — because as it stands, a declared unique is untrue of rows the platform's own automation wrote.

Option 1 is what makes a declared unique mean what it says without every hook author knowing a split exists. Whichever wins, the residual question this card cannot answer is what to do with already-minted duplicates on live installs — in the reporting app the numbers have already propagated into notification bodies, approval trails and a cross-reference field, so renumbering is off the table there; they need to be reported, not silently rewritten (same posture #8686's ruling took).

Repro

Single-tenant install, any object with an autonumber field:

1. create one record through REST/Console as a signed-in user (session carries an organization);
2. create one record on the same object from a hook / scheduled job / custom endpoint under a system context with no organization;
3. read the numbers and _objectstack_sequences for that object.

Two sequence rows, one org_… and one __global__, each counting independently. Status codes stay green throughout — watching responses will not show it.

Related

• Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 — the seed-loader producer of the same split. Fixed by fix(runtime): stamp seed rows with the install's organization so one object runs one autonumber scope #8832; this card is the residual producer.
• Observation: package permission sets are materialized with a tenant-less system context, so sys_permission_set rows land organization-less #8672 — measured the primitive ({ isSystem: true } insert ⇒ organization_id NULL) on sys_permission_set, filed as an observation because an org-less row is defensible for that object. On application objects it is not.
• Autonumber counter neither syncs to MAX(existing) per tenant nor re-checks on collision — warm-DB creates 409 in bursts, each failure burning a number (25 retries observed) #5495 / Engine fallback autonumber: counter seeds once and never resyncs; collisions burn numbers with no recheck (residual split from #5495) #6806 / seedAutonumber 的播种扫描是「取前 5000 行、不排序、不按前缀过滤」的 MAX —— 超过 5000 行的对象会播种出低于真实 MAX 的号 #6249 — counter-side autonumber cards. Confirmed not the remedy here for the same reason as in Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686: both counters are already correct within their scopes.
• tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 — tenant-scoped objects getting global unique indexes; adjacent to the "which partition does uniqueness mean" half.
• 多租户缺陷:unique 物化为全局唯一索引、无视 tenancy,与按租户分裂的 autonumber 序列自相矛盾(跨租户必然撞号 + 存在性探测泄露) #3696 — the original tenancy/uniqueness contradiction, closed against the multi-tenant reading. Worth noting this family now reproduces on a single-tenant install, in the organization dimension rather than the tenant dimension.

Downstream app-side tracking (private): steedos-labs/os-project-titanwind-ehr#1082 (the family card, with the per-object inventory) and #1056 / #1243 (symptom cards, held pending this).

[hotlong]

Triage: escalated to the maintainer — needs-user-decision · target:v17 · Bug. domain:* deliberately withheld; the ruling selects the lane. Triage seat (whole-repo Routine), fire 08:47Z.

Why this is not routable yet

The two options in "What a fix has to decide" do not land in the same package, so labelling a lane now would pre-empt the ruling:

option	lands in	lane
1 — a system-context write resolves the install's organization the way a session write does	packages/objectql (engine write path) + packages/core/src/security (context resolution)	domain:engine-core
2 — untenanted system writes stay, and the autonumber scope / COALESCE(…, '__global__') unique partition stops treating the pseudo-tenant as a peer	packages/drivers/driver-sql	domain:drivers

This is the #8772 shape, and that precedent is why the label is withheld rather than guessed: that card was routed four ways across three lanes before its ruling, and the ruling was the lane selector. A pre-applied label would have been wrong. Same here.

Premises re-verified on origin/main @ 6b6b606, not inherited from the card

• GLOBAL_TENANT is live in packages/drivers/driver-sql/src/sql-driver.ts and schema-drift.ts, with sql-driver-unique-tenancy.test.ts pinning the partition behaviour — the COALESCE half of the card is real and tested-in.
• fillAutoNumberFields is in driver-sql/src/sql-driver.ts and driver-turso/src/turso-driver.ts — the counter side is duplicated across two drivers, which the card does not say. Under option 2 the fix surface is two packages, not one. Worth knowing before the cost of the options is compared.
• The stamp itself is an injected field, not an explicit assignment: packages/objectql/src/registry.ts:555 injects organization_id from TENANT_SCOPE_FIELD_DEF into every tenant-scoped object, and engine.ts:8158 documents that the beforeInsert hooks are what stamp owner_id / organization_id / created_by. So option 1's edit site is the engine's stamp resolution, and the card's "read off the row, after stamping" description of fillAutoNumberFields is accurate — the defect is upstream of the counter, as the card says.
• Zero-hit discipline: no stampOrganization / applyTenancy / resolveWriteOrganization helper exists anywhere in packages/ (counter-probe: organization_id itself returns many hits in the same roots, so the narrow zero is real). There is no single chokepoint to change — which is a cost input for option 1 and belongs in the ruling.

target:v17 — stamped, with the reasoning stated so it can be reversed cheaply

Two of the four release-blocker classes hold, and the first is the decisive one:

• ① a defect on a released surface that users are hitting today — measured on 17.0.0 GA in a live single-tenant install, minting duplicate values on fields the app declared unique, across at least five objects;
• ③ existing-data / migration shape — duplicates are already minted and, per the card, have propagated into notification bodies, approval trails and a cross-reference field, so renumbering is off the table at the reporting install.

⚠️ Honest caveat, carried in these briefs for thirteen fires: this seat has no ruling on whether a target:v17 board means anything after GA, and has been leaving GA-surface cards un-nominated on that basis. I stamped this one anyway because it is the strongest class-① instance the board has seen — the defect is actively producing corrupt business identifiers on a customer install — and because over-marking for a day is the cheaper error. If the v17 board is closed at GA, drop the label in the same action that records that ruling.

What the ruling has to cover, beyond picking 1 or 2

The card names a residual it says it cannot answer, and it is the part with a deadline: already-minted duplicates on live installs. The card's stated posture — report them, do not silently rewrite — matches the posture #8686's ruling took, but it is not yet ruled here, and every hour of runtime on an affected install adds rows. Please rule on it in the same pass rather than leaving it to the implementing card.

Not a duplicate, and the neighbours are checked

• Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686 — the seed-loader producer, closed COMPLETED by PR fix(runtime): stamp seed rows with the install's organization so one object runs one autonumber scope #8832. Confirmed closed. This card is the runtime producer; the backfill cannot reach it, and is self-undoing on any install with server-side automation.
• Observation: package permission sets are materialized with a tenant-less system context, so sys_permission_set rows land organization-less #8672 — pm:on-hold, domain:identity, measured the same primitive ({ isSystem: true } insert ⇒ organization_id NULL) on sys_permission_set, where an org-less row is defensible. ⭐ This card is the evidence that the on-hold reasoning does not generalise, and Observation: package permission sets are materialized with a tenant-less system context, so sys_permission_set rows land organization-less #8672's restart condition should be read against it — on application objects the same primitive forks a declared unique. Whoever rules this should look at both together.
• tenant-scoped objects get GLOBAL unique indexes: 409-vs-201 enumerates other tenants' values, and a user's preferences silently stop persisting in their second org #8323 (tenant-scoped objects getting global unique indexes) and 多租户缺陷:unique 物化为全局唯一索引、无视 tenancy,与按租户分裂的 autonumber 序列自相矛盾(跨租户必然撞号 + 存在性探测泄露) #3696 (the original tenancy/uniqueness contradiction, closed against the multi-tenant reading) are the adjacent family; 多租户缺陷:unique 物化为全局唯一索引、无视 tenancy,与按租户分裂的 autonumber 序列自相矛盾(跨租户必然撞号 + 存在性探测泄露) #3696 is worth re-reading because this reproduces on a single-tenant install in the organization dimension, which is not the axis it was closed on.

⛔ Not dispatched, per the standing rule that a needs-user-decision card is never dispatched. It is not pm:blocked either — nothing upstream is in flight; it is waiting on a person.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling — Option 1 (system-context writes resolve the install's organization)

Provenance: maintainer, live PM chat 2026-08-15 (session session_01LXPH2ApQmyHYeZGHfYv7Xs), verbatim 「接受你的所有建议。」, accepting the 18-card decision-box four-axis analysis presented in that session. This card's accepted recommendation: Option 1 — a system-context write on a tenant-scoped object resolves the install's organization the way a session write does (the twin of #8686's ruling, one layer up). Recorded by the triage seat; needs-user-decision → pm:queue in the same write, and the ruling selects the lane as the escalation comment anticipated: domain:engine-core (the engine's stamp resolution — packages/objectql registry injection + the beforeInsert stamping path).

Binding points:

1. Single-tenant: derivable ⇒ derive and stamp. The __global__ fork must stop being minted by hooks/cron/system endpoints.
2. Multi-tenant: a system-context write must either carry an explicit organization or be refused loudly — ⛔ never silently default to __global__.
3. Already-minted duplicates: report, do not rewrite — same posture as Seed loader writes untenanted rows while the REST path stamps an organization — one single-tenant install runs two autonumber scopes and mints duplicate business identifiers, silently (17.0.0 GA) #8686. The implementing dev files the duplicate-reporting deliverable as its own follow-up card (dedupe first) rather than folding renumbering into this fix.
4. Cost input from the escalation's verification, carried forward: there is no existing chokepoint helper — the edit site is the engine's stamp resolution, and fillAutoNumberFields is duplicated in driver-sql and driver-turso (relevant to tests, not to the fix site).
5. Cross-reference: Observation: package permission sets are materialized with a tenant-less system context, so sys_permission_set rows land organization-less #8672's on-hold reasoning ("org-less rows defensible for sys_permission_set") does not generalize to application objects — this ruling is the evidence; read both together when touching the primitive.

Model floor: this changes write-path behaviour and adds a refusal (accept-set change) ⇒ claude-fable-5 mandatory; quota exemption (maintainer 2026-08-13) ⇒ opus only if fable is measured unavailable, recorded in the claim. target:v17 stays — blocker classes ① and ③ per the escalation.

---

Generated by Claude Code