Uh oh!
There was an error while loading. Please reload this page.
fix(components): apply new form defaultValues in the commit that renders them - #3001
Merged
Merged
Conversation
…ers them The form applies a `defaultValues` change by resetting react-hook-form to it. While that ran in a PASSIVE effect there was a window: the render had already committed, so the new inputs were mounted and interactive, but the form still held the old record. Anything typed in that window was destroyed — the pending `reset()` overwrote the whole record with `defaultValues`, dropping the field the user had just filled, with no error and nothing in the payload. It surfaced as the flaky wizard test fixed in #2983: a step transition changes `defaultValues`, and `note` typed on the new step vanished from the create body. That fix drained pending effects in the test, which AVOIDS the window; this one CLOSES it. Measured with the pre-fix test pattern, 1500 replays under CPU load: 6 failures before, 0 after. Running the reset as a layout effect is only half of it. The `form_change` subscription was silent across a reset by accident of ordering, not by design: `onAction` is usually an inline arrow, so its identity changes every render and the subscription effect re-runs each commit — and React runs every passive DESTROY before any passive CREATE, so the watcher was unsubscribed before the reset fired. Hoisting only the reset to the layout phase puts it AHEAD of that cleanup, so the still-live previous subscription sees it and a record landing looks like the user having edited every field it filled. That regressed #2968 deterministically (`changes=[{"category":"not-offered","status":"pending"}]`). Both `form.watch` subscriptions therefore move to the same phase, restoring the destroy-then-create order exactly. The new test pins the window shut without depending on timing: React flushes passive effects in tree order, so a probe sibling rendered before the form is guaranteed to run inside the window and types from there. It fails on every run against the previous code. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the product-side race behind #2982. #2983 fixed the flaky test; this fixes the form.
The bug
The form applies a
defaultValueschange by resetting react-hook-form to it. While that ran in a passive effect there was a window: the render had already committed, so the new inputs were mounted and interactive, but the form still held the old record. Anything typed in that window was destroyed — the pendingreset()overwrote the whole record withdefaultValues, dropping the field the user had just filled. No error, nothing in the payload.It surfaced as a flaky wizard test: a step transition changes
defaultValues, andnotetyped on the new step vanished from the create body. #2983 drained pending effects in the test, which avoids the window; this closes it.Measured with the pre-fix test pattern (no test-side drain), 1500 replays under 10 competing CPU hogs:
The half-fix that wasn't
Making the reset a layout effect alone regressed #2968, deterministically — 3/3 fail, 3/3 pass on pristine. Worth writing down, because the reason is not obvious:
The
form_changesubscription was silent across a reset by accident of ordering, not by design.onActionis usually an inline arrow, so its identity changes every render and the subscription effect re-runs each commit — and React runs every passive DESTROY before any passive CREATE, so the watcher was already unsubscribed when the reset fired. Hoisting only the reset to the layout phase puts it ahead of that cleanup, so the still-live previous subscription sees it, and a record landing looks like the user having edited every field it filled:So both
form.watchsubscriptions move to the same phase, restoring the destroy-then-create order exactly. That is the whole reason this diff touches three effects instead of one.The regression test
Deterministic, not statistical — a 1500-iteration probe is unfit for CI. It leans on a guarantee that actually holds: React flushes passive effects in tree order, so a probe sibling rendered before the form is guaranteed to run inside the window, and types from there. Fails on every run against the previous code.
(My first attempt used
flushSyncto open the window and was worthless —flushSyncalso flushes pending passive effects, so it closed the very gap it meant to open and passed on buggy code. Discarded.)A second case covers the risk this change carries: defaults that arrive late (edit-mode record landing) must still be adopted.
Verification
plugin-kanban/src/index.test.ts, hit abeforeAllimport timeout under a fully-parallel local run; it passes 3/3 alone and never touches the form renderer.form.tsxlint warnings unchanged (82 → 82), 0 errors; new test file 0 warnings.🤖 Generated with Claude Code