Skip to main content
sourceburg

Every fact machine-verified against its source

Typeface
Text size

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]

src/logic/getFieldArrayParentNames.ts @ c6c3d87
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]

src/logic/getFieldArrayParentNames.ts

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]

Timeline
  1. 2026-01-20

    issue #13260[4]

  2. 2026-05-09

    pr #13420

  3. 2026-05-09

    🐞 fix #13260: notify all matching field-array roots on nested setValue updates (#13420)[2]

  4. 2026-05-17

    comment by maxkostow[6]

  5. 2026-05-17

    comment by bluebill1049[7]

  6. 2026-05-17

    Revert "🐞 fix(useFieldArray): preserve managed field ids in array subscriber …" (#13452)[8]

  7. 2026-05-17

    Revert "🐞 fix #13260: notify all matching field-array roots on nested setValue updates (#13420)"[1]

  8. 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]