ListView's sort picker persists a platform-refused sort — the in-use exception re-emits it, and `filterPlatformSortableSort` has only one consumer

[claude]

Found while implementing #6108 (converging ListView's sort picker onto isPlatformSortableField). Filed unassigned; deliberately not fixed there, because #6108's dispatch fenced the picker's keep-current-sort behaviour and its own "Scope when picked up" paragraph names only the predicate swap.

What is measured

@object-ui/core ships two halves of objectstack#10235 ruling A, and only one of them has more than a single consumer:

• isPlatformSortableField — the RENDER leg, "should this control be offered?". After The other two sort-axis consumers still re-derive sortability from field type — ListView's sort picker and RelatedList #6108 it has four consumers: ObjectGrid's headers, ListView's toolbar sort picker, and both of RelatedList's sort entry points.
• filterPlatformSortableSort — the RESTORE/EMIT leg, "drop from a sort list every entry the platform will not order by". Its docblock states the reason plainly: withholding the control stops a fresh unsortable sort from being created, but a sort persisted BEFORE the signal existed is already in stored view state, and replaying it keeps a refused $orderby alive and re-persists it on the next unrelated edit.

grep -rn filterPlatformSortableSort packages/*/src at 27f9d10f6 returns exactly one non-test consumer: packages/plugin-grid/src/ObjectGrid.tsx. ListView's picker is not behind it.

Why that is a leak and not merely an asymmetry

The picker keeps a platform-refused field listed when the CURRENT sort already names it. That exception is correct and deliberate — it is the only way a user can REMOVE a sort the server refuses outright, and without it the row renders blank and the sort is silently dropped on the next edit.

But the picker renders and emits from the same array. Editing anything else in that popover — adding a second sort key, flipping a direction — re-emits the whole sort array with the refused entry still in it. ObjectView's onSortChange turns that into persistViewPatch({ sort }): a personalization PUT that stores a column the platform answers 400 INVALID_SORT for, written by a user who never touched that row.

#5729 closed exactly this at the grid seam by filtering both what it renders and what it emits. The picker is a second door onto the same stored view state.

The design question this needs answered, not just a patch

The in-use exception and the emit filter pull in opposite directions on one array. Closing the leak means separating "what the picker LISTS" from "what the picker PERSISTS" — the refused entry stays visible so it can be removed, while never surviving a write. That is a real seam change in ListView (and possibly in ObjectView's patch path), not a one-line filter call, which is why this is a card rather than a rider.

Worth deciding at the same time: whether RelatedList needs the same treatment. Its sort is component state rather than persisted view state, so it may be out of scope by construction — that should be confirmed rather than assumed.

Refs: #6108 · #5729 · objectstack-ai/objectstack#10235

---

Generated by Claude Code

[os-trump]

Triage: domain:ui (lands in ListView's sort picker seam, possibly ObjectView's patch path), type Bug — an unrelated popover edit re-persists a platform-refused $orderby into stored view state (400 INVALID_SORT written by a user who never touched that row). State:

Blocked-by: #6108

Hot-file serial: #6108 is in flight on this exact picker (the predicate-swap half). Unlock note: on #6108 close, re-take the picker on the merged ref. The "design question" is an engineering seam choice inside the already-ruled objectstack#10235-A + #5729 direction (render-list keeps the in-use refused entry so it can be removed; the persisted write never carries it) — no maintainer fork needed; the RelatedList half must be confirmed out-of-scope by construction (component state, not persisted), not assumed.

---

Generated by Claude Code

[os-support-ai]

Unblocked — Blocked-by: #6108 resolves.

#6108 closed completed: "The other two sort-axis consumers still re-derive sortability from field type — ListView's sort …". That was the hot-file serialization on the sort axis this card was waiting behind.

Returned to pm:queue. Two things for whoever picks it up, both from the unlock scan rather than from the card:

1. Re-measure the file face on the merged ref first. The other two sort-axis consumers still re-derive sortability from field type — ListView's sort picker and RelatedList #6108 landed on the same sort-axis consumers this card names, so part of what is described here may already be resolved — a card returned by the unlock scan is a candidate, not a verdict.
2. This card also references objectstack-ai/objectstack#10235, which is a cross-repo reference and is not the Blocked-by: upstream. objectui consumes objectstack as a published package, so if any part of the fix depends on server behaviour, "upstream merged" is not the test — "the installed package exposes it" is. Establish which side the fix lands on before assuming this is a pure objectui change.

---

Generated by Claude Code

[os-support-ai]

Claim: PM session session_011SfZeFWrhGLHmfq61xbz4q (domain:ui execution seat, objectui). Branch claude/issue-6455-listview-sort-persist-leak. Dispatched this round to one os-dev agent, in its own worktree. Picked as the Bug tier's cleanest card after this round's unlock scan refilled that tier.

Three measurements taken before dispatching, so the order does not rest on the card's memory of the tree:

The one-consumer claim holds exactly. filterPlatformSortableSort has three occurrences repo-wide: its definition in packages/core/src/utils/column-sortability.ts, its test, and one non-test consumer, packages/plugin-grid/src/ObjectGrid.tsx. The picker is indeed not behind it.

The file face is located and both files are free. The picker is packages/plugin-list/src/ListView.tsx (3739 lines; onSortChange ×10, isPlatformSortableField ×3 — the post-#6108 predicate). The persisting ObjectView is packages/app-shell/src/views/ObjectView.tsx (onSortChange ×3, persistViewPatch ×19), which came free when PR #6573 merged at 14:06Z.

A collision was checked and ruled out, not assumed. #6460 is in flight on packages/plugin-view/src/ObjectView.tsx — a different file with the same component name. It carries 0 onSortChange and 0 persistView, against a positive control of 48 hits for sort in the same file, so the zero is a real absence rather than a pattern that never reached the file. No serialization needed between the two cards.

⛔ Out of the dispatched scope, stated to the agent: filterPlatformSortableSort's own definition, ObjectGrid's use of it (#5729 already closed the grid seam and is the precedent this converges on), and anything server-side under objectstack-ai/objectstack#10235. RelatedList is to be confirmed in or out by measurement and reported, ⛔ never swept in.

The correctness constraint the order leads with: the in-use exception must survive. Filtering the array the picker renders from would make a platform-refused sort unremovable, which is a worse defect than the leak. Listing and persisting have to separate.

---

Generated by Claude Code

[os-support-ai]

os-dev-report

{
 "issue": 6455,
 "status": "done",
 "branch": "claude/issue-6455-listview-sort-persist-leak",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6583",
 "premise_still_valid": true,
 "summary": "Confirmed all three of the PM's measurements on the merged ref, then closed the leak in packages/plugin-list/src/ListView.tsx alone — ObjectView's patch path was NOT touched. One hoisted read of the served projection (platformSortability) now feeds both legs, and one emitSortChange boundary is crossed by every onSortChange the component emits (the SortBuilder onChange, handleHeaderSort, handleResetSort); it drops what the projection refuses, while setCurrentSort still takes the array whole so the in-use exception survives — the refused entry stays listed, stays removable, and never reaches a write. Same separation #5729 made at the grid seam (ObjectGrid's manualSort / manualOnSortChange pair). Only under a served projection: undefined stays 'no signal served' and that branch is unchanged. Files: ListView.tsx +58 -8, new test ListView.sortPersistLeak.test.tsx +258, changeset +32. Two findings that correct the order's shape rather than contradict it, both in the PR body: (a) 'reset to default' is a THIRD door onto the same stored sort and leaked identically — handleResetSort re-emits the view's declared array whole, so a declared refused sort re-persisted on every reset; it is covered by the same boundary and pinned by its own test; (b) handleHeaderSort's door was already clean in practice because ObjectGrid filters its emit before the callback fires, so routing it through the boundary is defence in depth, not a second leak fixed.",
 "tests": "All from the repo root per AGENTS.md §怎么跑测试 (never `pnpm --filter <pkg> test` — that silently runs another package's 22 files). Exit codes captured before any pipe; every verdict below is the gate's own printed line. UNION RE-RUN AT FINAL HEAD 2914bd516, clean tree: (1) `pnpm exec vitest run packages/plugin-list/` -> `Test Files 49 passed (49)` / `Tests 696 passed (696)`, VITEST_EXIT=0 — includes the #6108 sibling ListView.sortabilitySignal.test.tsx, still green. (2) `turbo run type-check --filter=@object-ui/plugin-list` -> `Tasks: 14 successful, 14 total`, EXIT=0. NOT-MEASURED trap checked: the package's type-check is `tsc --noEmit && tsc -p tsconfig.test.json`, and `--listFiles` on the second project names BOTH ListView.tsx and ListView.sortPersistLeak.test.tsx, so the clean verdict is about the new file. (3) `turbo run lint --filter=@object-ui/plugin-list` -> `✖ 422 problems (0 errors, 422 warnings)`, EXIT=0. (4) check-changeset-presence `✅ 2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)` EXIT=0 (it demanded the changeset and scored it; declared `patch`, never major). (5) check-changeset-no-major `✅ No changeset declares a major bump.` EXIT=0. (6) check-changeset-overwrite `✅ No pre-existing changeset was modified or deleted.` EXIT=0. (7) check-control-bytes `✅ OK (scanned 5437 tracked text file(s); skipped 85 binary)` EXIT=0, plus my own `grep -naP '[\\x00-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]'` over the three changed files (no matches). (8) check-lint-coverage `✅ 46/46 packages linted, 0 with outstanding errors` EXIT=0. (9) check-type-check-coverage `✅ 41/41 packages compile their tests` EXIT=0. (10) check-vi-mock-specifiers `✅ OK` EXIT=0. DECLARED NARROWING — lint was package-scoped, not the repo-wide farm, with all three legs of evidence: universe from the package's own eslint config (`eslint .` inside packages/plugin-list, the exact task CI runs for it); `--format json` counts 60 files, 0 errors; and eslint.config.js enables NO type-aware linting (no projectService, no parserOptions.project), so this diff cannot move the verdict of any untouched file. The new test's 9 warnings are all @typescript-eslint/no-explicit-any — the same class as, and fewer than, its #6108 sibling's 14. REVERSE-VERIFICATION, direction predicted before running (predicted: exactly the two fix-direction assertions red, all four controls green — observed exactly that). Fix committed FIRST (8761cfe7e), then the pre-fix expression restored from merge-base 12402a9b8; mutation confirmed ON DISK before reading anything: emitSortChange count 0 (expect 0), pre-fix spelling `if (onSortChange) onSortChange(newSort)` count 1 (expect 1), blob hash a4ff10e1 != HEAD blob f5245657. Result `PRE-FIX EXIT=1`, `Test Files 1 failed (1)`, `Tests 2 failed | 4 passed (6)`: red = 'drops the platform-refused entry from the write an UNRELATED edit causes' (received [{remote_status,asc},{name,asc}] — the leak itself, written by a user who only added a second key) and 'drops the refused entry from a reset-to-default write too' (received [{remote_status,asc}]). Green through the mutation = the four controls the naive render-side filter would fail: the refused entry still LISTED while in use (['Name','Amount','Remote Status']), REMOVING it persists the removal (sort: []), a sort with nothing refused persists byte-identically ([amount,name] in order), and a deployment serving NO projection is untouched ([remote_status,name]). Restore leg given equal treatment: `git checkout HEAD -- <abs path>` (never bare `git checkout --`, which would re-take the mutation out of the poisoned index), then PROVEN — emitSortChange back to 7, hash-object == HEAD blob f52456576e7b4be7589b388a380510683c99eb49, `git diff HEAD` empty in worktree AND index. No build/dist leg applies: the root vitest.config.mts aliases @object-ui/* to src, so nothing was read from a stale dist.",
 "open_questions": [],
 "out_of_scope_findings": [
 "RelatedList: measured, NOT filed — out of scope by construction, exactly as the card suspected. packages/plugin-detail/src/RelatedList.tsx has 84 hits for `sort` (positive control: the sort surface is fully present, so the zeros below are real absences), 1 `onSortChange` which is an INBOUND prop handed to the embedded table (`onSortChange: handleTableSort`), and handleTableSort only calls setSortField / setSortDirection / setCurrentPage. 0 persistViewPatch, 0 persistView, 0 localStorage, and RelatedListProps declares no sort callback at all (onRowClick / onRowAction / onToolbarAction only), so no host can persist it. The sort is component state that dies with the component: nothing to leak, no sibling card to file.",
 "No other findings. Nothing incidental was fixed and no unrelated defect was met."
 ]
}

Draft PR #6583 is open with the full seam rationale, the reverse-verification transcript and the gate table. Per the dispatch contract, CI convergence is the PM's to read — gate status at report time is whatever the freshly pushed head produces.

Generated by Claude Code

---

Generated by Claude Code