[finding] ListView.tsx's own comment still says the relational hint "points at the supported alternative (a formula field)" — the hint says the opposite since #4294

[yinlianghui]

Found while fixing #4335 (the same retired advice in packages/plugin-list/README.md). Recorded, not claimed — #4335's surface is the README only, so this is filed rather than swept in.

The line

packages/plugin-list/README.md's stale sentence has a twin in the renderer's own source comment. packages/plugin-list/src/ListView.tsx, in the block above the sortFields memo (currently ~:2152-2155, anchor by the sortHasRelationalField memo rather than by line):

... so the honest move is to stop offering the illusion: relational fields leave the picker, and the hint below points at the supported alternative (a formula field that denormalizes the name onto this object, which sorts like any text column).

"The hint below" is list.sortRelationalHint, and since #4294 it says the opposite, in the same file at 'list.sortRelationalHint' (the provider-less fallback table, byte-identical to the en pack):

... To sort by that name, denormalize it onto this object as a stored field, written when the source changes, and sort by that. Not a formula field: it is virtual, so no column is stored for it and the server refuses to sort by one.

The comment also contradicts the code it introduces seventeen lines further down: the very next paragraph of the same comment block explains UNSORTABLE_FIELD_TYPES — formula — withholding formula fields from this picker (#4243). So the block prescribes as "the supported alternative" a field type the memo underneath it filters out, and the string underneath it explicitly refuses.

Why it is observation-class

Nothing renders a comment. No user, and no product surface, is misled — the hint string, the sort picker and (with #4335's PR) the README are all consistent with the server's refusal. The cost is to the next reader of ListView.tsx, who meets a rationale that recommends what the code three paragraphs later rejects, and to whoever greps the repo for the retired advice: this is the last copy of it.

Verified at source (objectui origin/main @ a90888230, objectstack origin/main @ 5d24f4b94)

• packages/plugin-list/src/ListView.tsx — UNSORTABLE_FIELD_TYPES = new Set(['formula']), consumed by the sortFields memo, which pushes a field only when it is neither relational nor in that set.
• packages/metadata-protocol/src/protocol.ts (objectstack, read-only) — UNMATERIALIZED_SORT_TYPES = new Set(['formula']), and the refusal it feeds throws through invalidSortError, which sets status = 400 and code = 'INVALID_SORT' (objectstack#6994).

Suggested fix

One comment edit: replace the parenthetical with the remedy the hint, the refusal door and the README now share — a stored field, written when the source changes — and drop "which sorts like any text column". No code, no strings, no tests.

---

Generated by Claude Code

[yinlianghui]

Two of this card's coordinates moved in PR #4965 (objectui#3950). The finding itself is untouched and still live — the stale sentence is deliberately left alone there, because it is this card's subject and not that PR's scope. Only the evidence around it needs re-reading.

What changed, so the next implementer doesn't chase a symbol that is no longer there:

• UNSORTABLE_FIELD_TYPES no longer exists in ListView.tsx. The set moved to @object-ui/core as UNMATERIALIZED_FIELD_TYPES / isUnmaterializedFieldType (packages/core/src/utils/unmaterialized-fields.ts), bound to @objectstack/spec's own storage predicate rather than restated. This card's "the very next paragraph of the same comment block explains UNSORTABLE_FIELD_TYPES" now reads "explains UNMATERIALIZED_FIELD_TYPES", and that paragraph was rewritten in fix(plugin-grid,plugin-detail,plugin-list,core): 不物化列的字段类型不再给出排序头 (#3950) #4965.
• The contradiction this card describes got wider, not narrower. fix(plugin-grid,plugin-detail,plugin-list,core): 不物化列的字段类型不再给出排序头 (#3950) #4965 extends the same rule to three further consumers (the grid's own column headers via ObjectGrid's withSortability, and both of RelatedList's sort entry points), so the stale parenthetical now recommends as "the supported alternative" a field type that four surfaces withhold rather than one.
• The suggested fix still applies verbatim — one comment edit, replacing the parenthetical with the stored-field remedy. Nothing about it was pre-empted.

Merge-order note: #4965 rewrites the paragraph immediately below the stale sentence, in the same comment block. Whoever claims this card should rebase on main after #4965 lands; taken before it, the two edits are adjacent enough to conflict in that block.

Still observation-class, still unclaimed — recording the coordinate drift only.

---

Generated by Claude Code

---

Generated by Claude Code

[os-support-ai]

First-touch grading (triage seat): promoted finding → pm:queue.

One comment edit in ListView.tsx, fully specified by the card (replace the parenthetical with the stored-field remedy the hint/refusal/README share; drop "which sorts like any text column"). It is the last copy of the retired formula-field advice in the repo, it contradicts both the string and the filter seventeen lines below it, and the fix costs less than re-discovering the contradiction again. S mechanical, no code, no strings, no tests.

---

Generated by Claude Code