Repository navigation
v18 upgrade: stored views with data.provider 'api' are refused at rehydration with no conversion — the upgrade should migrate or report them #23271
Description
Filed by the repo:cloud#1 seat (seat post #6026, session session_01WVbr5J6u8BHh8EyFtcWciH) under ruling objectstack-ai/cloud#2866 A (6146394952). The maintainer ruled that tenant databases are migrated by the platform's v18 upgrade script, not by cloud. The maintainer's lane rule: anything that blocks cloud's v18 upgrade is high priority. Source: the cloud re-pin report objectstack-ai/cloud#2709 6145524807 (data_shape_changes), at framework 01a3421f42.
What happens
- The change:
1912af47ba(feat(spec)!: retire the view-levelapidata source — a view binds its object or static rows; an API call is the page element's binding (#23082) #23160) refuses a stored view row whosedata.provideris'api'(withread/writeblocks) at rehydration. It gives a prescription, but it deliberately ships no D2 conversion, because the replacement lives on a page element. - Read only: cloud's code writes no such view. Whether tenant-authored rows exist was not measured; cloud's upgrade rehearsal (objectstack-ai/cloud#2867) will count them.
Ask
The v18 upgrade either moves such a view to the page-element form the prescription names, or lists it in the ceremony's report so an owner can act. A silently unserved view is what to avoid. If the lane judges that no deployment can hold such rows, closing this with that evidence is fine.
Generated by Claude Code
Activity
objectstack-fleet commentedon Oct 13, 2026
Triage: first grade,
bug·priority:p1·target:v18·domain:spec, intopm:queue(findingremoved). Stored views withdata.provider: 'api'are migrated to the page-element form by the v18 upgrade, or refused and listed in its reportTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-13T14:05Z. ⛔ Not a claim, ⛔ not a dispatch.Why p1
target:v18: ruling A on objectstack-ai/cloud#2866 (6146394952) says the platform's v18 upgrade migrates tenant databases. The maintainer's lane rule is that whatever blocks cloud's v18 upgrade is high priority. The filer's p1 stands.Lane: every route the card names is spec-owned:
packages/spec/src/conversions/registry.ts, as finding(security): controlled_by_parent derives its master through a REQUIRED LOOKUP (runtime and lint, third tier) where ADR-0055 §1 requires exactly one required master_detail and fails closed — a widening no record states #23100 shippedcbp-master-detail-required-defaulted;packages/spec/src/migrations/entries/semantic/), applied byos migrate meta;So this is
domain:spec. The lane chooses the route per shape, as the card says. A D2 conversion must stay lossless, declared, loud and tested; a shape that cannot be converted losslessly is refused and listed.Family: v18 upgrade: stored flows whose get/update/delete_record filter operand is a {…} token are refused at boot with no conversion — every deployment's automations built on the old spelling stop running #23269, v18 upgrade: stored controlled_by_parent objects without exactly one master_detail (two masters, none, a required lookup, required:false) are denied after upgrade with no conversion or fate #23270 and v18 upgrade: stored views with data.provider 'api' are refused at rehydration with no conversion — the upgrade should migrate or report them #23271 share one report channel: what the upgrade converts, and what it refuses and lists. One family dispatch is fine, with the chain head's claim naming the shared branch and each card keeping its own
Fixesline.⛔ A runtime that tolerates the old spelling is not the ask, on any of the three cards.
Clause ②: no. A conversion of stored rows into what the v18 doors already accept widens nothing.
Direction:
apidata source — a view binds its object or static rows; an API call is the page element's binding (#23082) #23160 (1912af47ba) refuses a stored view whosedata.provideris'api'at rehydration, with a prescription and no conversion. The upgrade moves such a view to the page-element form where the move is mechanical, or refuses and lists it by view.Studio's half is the view-level
apidata source is retired in @objectstack/spec (objectstack#23082): delete theViewData.provider === 'api'readers, keep the approvals inbox's code-builtApiDataSourceobjectui#12325 (pm:on-hold), which deletes the authoring path. It does not wait on this card.Triage: lands in
packages/spec/src/conversions/registry.tsorpackages/spec/src/migrations/(domain:spec); rationale: stored v17 rows must reach the v18 refusal through the upgrade, not at rehydration.objectstack-fleet commentedon Oct 13, 2026
Claim: PM loop round 1 (#23271, folded into the v18 stored-row family dispatch whose chain head is #23269) · 2026-10-13T14:38Z
Session:
session_01BRQ9Mp1yH7R1az6MaUM18HAccount:
os-justin(the seat's linked user asGET /useranswers it; the card's assignee from this act)Branch:
claude/issue-23269-v18-stored-row-fates(shared; this card keeps its ownFixes #23271line in the family PR)Worktree:
objectstack-issue-23269Domain:
domain:specSeat:
domain:spec#2(seat post #18549)File surface: as the chain head's claim on #23269 states (
packages/spec/src/conversions/**,packages/spec/src/migrations/entries/semantic/**, their tests and generated projections, one changeset); stop on breach and explain in the report.Container & model: one family dispatch,
mode:subagent,model: default tier. ACONTRACT_REVIEW_TIERreview precedes the queue.Clause-②: no (stored v17 rows are converted into what the v18 doors already accept, or refused and listed)
Responsibility: as the chain head's claim states, for this card's shape
Thread-read: 6147391920
Serial constraints cleared: the fold and its five gates are answered in the chain head's claim on #23269.
This act moves the card
pm:queue→pm:dispatchedand assignsos-justin.Generated by Claude Code
objectstack-fleet commentedon Oct 13, 2026
Landed with #23269 · PR #23315 →
572ecfb2e; the landing record is on #23269.pm:dispatchedis removed in this act. ·domain:specseat 2 · sessionsession_01BRQ9Mp1yH7R1az6MaUM18HGenerated by Claude Code