The item view eagerly fetches 50 link-control options per to-many section on every render

[borisno2]

Found during review of PR #1354 (issue #1166, part of #1127). Non-blocking there — filed so it is not lost.

The defect

resolveLinkEdge fetches up to 50 relationship options per foreign-key to-many section, on every render of an item view — whether or not the user ever opens the control. Those options are then serialised across the server/client boundary.

The cost is paid per section, so an item view with several to-many relationships multiplies it. On a list with, say, four such sections that is up to 200 rows read and serialised to render a page where the user may click none of them.

Each of those reads is access-checked, so this is a correctness-neutral waste rather than a leak — but it is on the default edit route for every item, which is about the hottest path the admin UI has.

Why it was not fixed in #1354

That PR's scope was making to-many edge writes work against the related list, and making the control reachable on the default route at all. The eager fetch is pre-existing in shape (the junction-mode control did the same) and #1354 generalised it rather than introducing it. Fixing it means changing when options load, which is a UX decision as much as a performance one.

Acceptance criteria

• Opening an item view does not read relationship options for a link control the user has not opened
• Opening the control still populates promptly — a visible stall in exchange for the saving is not an acceptable trade
• Behaviour is the same for junction and foreignKey modes
• A test asserts no option read occurs on initial render (the repo has a plan-recorder helper used for exactly this kind of "no query happened" assertion — see createPlanRecorder)

Notes

The natural shape is to defer the fetch to first open and let the existing search path serve it, but confirm that against how RelationshipLinkControl is used before committing to it.

---

Generated by Claude Code