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
{{ message }}
Repository navigation
fix(rest): the one-request record page refuses a related list keyed by a user field — 'owner' is not a lookup or master-detail field that references 'sys_user' #29946
Repro: a record page on sys_user (duly's duly_member) declares a related list of duly_task keyed by owner, which is a Field.user. Open it full page at /sys_user/record/<id>/page/duly_member.
18.2.0: the page renders.
18.3.0: the console shows "could not load this record / VALIDATION_FAILED". The request POST /api/v1/data/sys_user/<id>/page answers:
400 VALIDATION_FAILED: 'owner' on 'duly_task' is not a lookup or master-detail field that references 'sys_user'.
Cause: in packages/rest/src/record-page-routes.ts (the one-request record page, #27713 / #28682), the related-list check accepts only RELATIONSHIP_TYPES (lookup, master_detail) whose reference is the page's object. A user field references sys_user by definition, but it is refused.
Expected: a user field (and an owner field, if that is a separate type) counts as a relationship to sys_user in this check, as it does in the related list's own row query.
Impact: any app record page on sys_user with a related list by an owner or assignee user field fails to open full page.
Separately, in the same pass: a url action at record_header on sys_user (served in the metadata) no longer renders in the 18.3 console's header menu, in the drawer or on the full page. 18.2 rendered it. Evidence is in the duly project's duly-18.3-browser-check/REPORT.md (R1).
Read fresh. A regression in 18.3.0 (renders on 18.2.0). POST /data/sys_user/:id/page refuses a related list keyed by a user field with 400 VALIDATION_FAILED, because record-page-routes.ts's check accepts only lookup and master-detail. So any app record page on sys_user with an owner or assignee related list fails to open. A shipped regression, fixed in a patch release, so p1.
Split: the second defect in the body (a url action at record_header on sys_user no longer rendering in the 18.3 Console) is a domain:ui regression. Triage files it as its own card.
Claim: PM loop round 2
Session: session_01WGufzijwvEjcKQArbvuX9p (dev: os-dev card thread; seat session_01WGufzibcN9oHa8kDbTTnL5)
Account: os-support-ai
Branch: claude/project-thread-nzsli6 (harness-pinned thread branch; platform exception to claude/issue-<n>-<slug>)
Worktree: the dev thread's own container checkout
Domain: domain:server
Seat: domain:server#6
File surface: packages/rest/src/record-page-routes.ts (the related-list invalid_relationship check), the engine's existing user-reference judgement it reuses (read, or a small shared export), route pins, one patch changeset (stop on breach; explain in the report)
Container & model: S, mode:thread, model: TIER_DEFAULT (dispatch-gates --tier: no path-derived mandate), effort: medium
Clause-②: no
Metadata-protocol: none
Responsibility: the platform's own record page route (its related-list check accepts only lookup/master-detail and refuses a user field, which references sys_user by type) | none — the related list's own row query follows a user field | every app with a sys_user record page whose related list is keyed by an owner/assignee user field; 18.3.0 regression
Thread-read: 6610340522
Premise: holds (card reproduced from objectstack-ai/duly#185 on 18.3.0; triage 6610340522; the dev re-measures on main)
Serial constraints cleared: none (no in-flight claim of this seat on record-page-routes.ts; the dev re-checks open PRs at PR time)
Stamp: 2026-11-03T17:11Z
Order: /mnt/project-files/server-orders/29946.md (project files). Routed to this seat by triage (Notify: release-blocker, mailbox pm:mailbox — domain:server#6 · os-support-ai #29907, comment 6610447917). Scope: the related-list check only; the url action at record_header is a separate domain:ui card.
Landed · 2026-11-03T20:36Z · PR #29965 merged through the queue as 18112bfa (ACCEPT 6612787401; review PASS 6612013793, delta PASS 6612763022). pm:dispatched removed with the close. The record page's related-list check now asks the spec's referenceTargetOf, so a related list on sys_user keyed by a user field opens again (18.3.0 regression from #27713); a field that does not reference the page's object is still 400 invalid_relationship. The url action at record_header from the card body is the separate domain:ui card.
Activity
objectstack-fleet commentedon Nov 3, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: first-touch audit · p1 ·
domain:server·pm:queue· 18.3.0 regression · 2026-11-03T17:01Z⛔ Not a claim.
POST /data/sys_user/:id/pagerefuses a related list keyed by auserfield with400 VALIDATION_FAILED, becauserecord-page-routes.ts's check accepts only lookup and master-detail. So any app record page onsys_userwith an owner or assignee related list fails to open. A shipped regression, fixed in a patch release, so p1.urlaction atrecord_headeronsys_userno longer rendering in the 18.3 Console) is adomain:uiregression. Triage files it as its own card.Generated by Claude Code
objectstack-fleet commentedon Nov 3, 2026
domain:server#6 · os-support-ai · session_01WGufzibcN9oHa8kDbTTnL5
Claim: PM loop round 2
Session:
session_01WGufzijwvEjcKQArbvuX9p(dev: os-dev card thread; seatsession_01WGufzibcN9oHa8kDbTTnL5)Account:
os-support-aiBranch:
claude/project-thread-nzsli6(harness-pinned thread branch; platform exception toclaude/issue-<n>-<slug>)Worktree: the dev thread's own container checkout
Domain:
domain:serverSeat:
domain:server#6File surface:
packages/rest/src/record-page-routes.ts(the related-listinvalid_relationshipcheck), the engine's existing user-reference judgement it reuses (read, or a small shared export), route pins, one patch changeset (stop on breach; explain in the report)Container & model:
S,mode:thread,model: TIER_DEFAULT (dispatch-gates --tier: no path-derived mandate),effort: mediumClause-②: no
Metadata-protocol: none
Responsibility:
the platform's own record page route (its related-list check accepts only lookup/master-detail and refuses a user field, which references sys_user by type) | none — the related list's own row query follows a user field | every app with a sys_user record page whose related list is keyed by an owner/assignee user field; 18.3.0 regressionThread-read: 6610340522
Premise: holds (card reproduced from objectstack-ai/duly#185 on 18.3.0; triage 6610340522; the dev re-measures on main)
Serial constraints cleared: none (no in-flight claim of this seat on
record-page-routes.ts; the dev re-checks open PRs at PR time)Stamp: 2026-11-03T17:11Z
/mnt/project-files/server-orders/29946.md(project files). Routed to this seat by triage (Notify: release-blocker, mailbox pm:mailbox — domain:server#6 · os-support-ai #29907, comment 6610447917). Scope: the related-list check only; theurlaction atrecord_headeris a separatedomain:uicard.objectstack-fleet commentedon Nov 3, 2026
domain:server#6 · os-support-ai · session_01WGufzibcN9oHa8kDbTTnL5
Landed · 2026-11-03T20:36Z · PR #29965 merged through the queue as
18112bfa(ACCEPT 6612787401; review PASS 6612013793, delta PASS 6612763022).pm:dispatchedremoved with the close. The record page's related-list check now asks the spec'sreferenceTargetOf, so a related list onsys_userkeyed by auserfield opens again (18.3.0 regression from #27713); a field that does not reference the page's object is still400 invalid_relationship. Theurlaction atrecord_headerfrom the card body is the separatedomain:uicard.