A field-array fix survived eight days before its author reverted it
react-hook-form shipped a fix for stale field-array values on 9 May. On 17 May the maintainer pulled it back out and landed a regression test instead.
Incident: MAY 17, 2026react-hook-form/react-hook-formBy the desk
Breaking
For eight days react-hook-form carried a fix that was supposed to make nested setValue calls reach every field array watching the name being written. It came back out on a Sunday night, and the commit that replaced it added no behaviour at all.
The fix landed on 9 May as part of pull request 13420, which claimed to close an issue opened in January about field values in useFieldArray failing to update after a setValue call.[2][4] Its whole mechanism was a new helper that walked a dotted field name outward and collected every registered ancestor that looked like an array root.[5] The loop rebuilt the prefix one segment at a time and pushed any prefix that was both a known name and immediately followed by a numeric index.[5]
3export default (names: Set<InternalFieldName>, name: InternalFieldName) => {4 const parts = name.split('.');5 const matches: string[] = [];6 let prefix = parts[0];78 for (let i = 1; i < parts.length; prefix += '.' + parts[i++]) {9 !isNaN(+parts[i]) && names.has(prefix) && matches.push(prefix);10 }Eight days later a user reported on the pull request that the new notification path was remounting components and stealing focus mid-keystroke.[6] The maintainer asked for a reproduction, and then, without waiting for one, reverted the change outright about forty minutes later.[7][1] The revert deleted the helper file in its entirety rather than narrowing the condition that produced the extra notifications.[1]
Before · ca01f65
-import type { InternalFieldName } from '../types';--export default (names: Set<InternalFieldName>, name: InternalFieldName) => {- const parts = name.split('.');- const matches: string[] = [];- let prefix = parts[0];-- for (let i = 1; i < parts.length; prefix += '.' + parts[i++]) {- !isNaN(+parts[i]) && names.has(prefix) && matches.push(prefix);- }-- return matches;-};After · dfcebdb
the file did not exist at this revision
Forty minutes after the revert the same maintainer landed a test-only commit adding regression coverage for exactly the key-thrashing behaviour that had just been removed.[3] That ordering is the interesting part: the project chose to encode the symptom it had observed before it had a fix that survived contact with the symptom.[3] A separate revert of a related field-array change had gone in six minutes before the first one, so two fixes to the same subsystem came out on the same evening.[8]
2026-01-20
issue #13260[4]
2026-05-09
pr #13420
2026-05-09
🐞 fix #13260: notify all matching field-array roots on nested setValue updates (#13420)[2]
2026-05-17
comment by maxkostow[6]
2026-05-17
comment by bluebill1049[7]
2026-05-17
Revert "🐞 fix(useFieldArray): preserve managed field ids in array subscriber …" (#13452)[8]
2026-05-17
Revert "🐞 fix #13260: notify all matching field-array roots on nested setValue updates (#13420)"[1]
2026-05-17
🧪 test(useFieldArray): regression coverage for descendant setValue key thrashing (#13420) (#13453)[3]
What we know now (written later: MAY 28, 2026)
Eleven days later the original issue picked up its first comment since January, from a reader reporting the same broken behaviour.[9]