Follow-up to #2991, which had to defend against this path. It turned out to be a defect of its own.

The bug

loading in ModalForm / DrawerForm / TabbedForm / SplitForm is only ever set true once — by useState(true) — and thereafter only ever set false. A recordId change re-enters the fetch effect without going back through the loading branch, so:

• the form stays mounted showing, and accepting edits to, record A's values;
• nothing indicates a different record was asked for;
• when B lands it replaces them in place.

Anything typed in that window read as A's on screen but would have been submitted against B.

Reading the same effect closely surfaced a second defect: no staleness guard, so two overlapping reads land in completion order rather than request order. Ask for B then C, and a slow B arriving last leaves the form showing B while the caller asked for C.

Both are the same thing from the user's side — the form displays a record nobody asked for — so both are fixed here.

ObjectForm already re-enters loading before its fetch (ObjectForm.tsx:460), which is why this only ever reproduced on the four sectioned variants.

The fix

• Re-enter the loading state on a change of record, so the previous record is off screen while the next is in flight. Gated on the record actually changing — the effect also re-runs on initialData/initialValues identity churn (callers rebuild those objects every render), and flashing the loading state for that would thrash.
• Mark the read stale in the effect's cleanup, so a response that is no longer awaited is dropped instead of overwriting a newer record.

Also fixed — a consequence of the above

Hiding the form unmounts the inner renderer, and that renderer is the only thing that reports dirtiness via onDirtyChange; it gets no chance to report false on the way out. Without clearing the flag, the overlay's unsaved-input guards from #2998 would stay armed for input belonging to a record no longer on screen — a plain refresh would prompt, and closing would offer to discard nothing.

I caught this only because #2998 landed hours earlier; it is exactly the kind of interaction a "just add setLoading(true)" change would have shipped silently.

Verification

• New recordSwapLoading.test.tsx drives each of the four containers through a real swap with a findOne the test resolves by record id, so both the stale-record and the out-of-order cases are deterministic rather than timing-dependent. Against the previous code all 11 fail — the two core assertions read expected 'Record One' not to be 'Record One' and expected 'Record Two' to be 'Record Three'.
• The dirty-flag guard is mutation-verified: dropping only that one line fails its two tests with expected true to be false.
• npx vitest run packages/plugin-form/ packages/components/ packages/app-shell/ → 315 files / 2627 tests pass.
• @object-ui/plugin-form type-check clean; lint 0 errors (the 2 unused-disable warnings are pre-existing, in EmbeddableForm/MasterDetailForm).

🤖 Generated with Claude Code