You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Using onChangeAsync in an array field causes isFieldsValidating to always be true after calling removeValue #2234
When using a validators config which has both onChangeListenTo and onChangeAsync in a subfield of an array mode field, removing any entry but the last of the array field will cause the listened-to fields in each shifted entry to be stuck on isValidating: true.
This does not happen when onChangeListenTo is included with onChange.
This does not happen when onChangeListenTo is not included with onChangeAsync.
In the example sandbox, click the add button twice, then remove the first row and click submit.
Notice in the console logs that all errors are empty, and that the field meta for list[0].operator shows isValidating: true, even though it does not have a validator.
Comment out line 70, repeat the above steps, and notice that the form submits as normal.
Uncomment line 70, change onChangeAsync on line 71 to onChange, repeat the above steps, and notice that the form submits as normal.
Expected behavior
On aform submit, the listened-to field should show isValidating: false, and the form submission should succeed.
Removing an array row changes every subsequent field path, so pending async-validation bookkeeping keyed by the old indices must be canceled or remapped atomically with field meta. A generation/token per validation run would also prevent a promise started for the removed row from later setting isValidating on the field that shifted into its path. Tests should remove the first and middle rows while validators are unresolved, resolve them in reverse order, and assert both field-level and form-level validating counters return to zero.
Activity
hiSandog commentedon Jul 10, 2026
Removing an array row changes every subsequent field path, so pending async-validation bookkeeping keyed by the old indices must be canceled or remapped atomically with field meta. A generation/token per validation run would also prevent a promise started for the removed row from later setting
isValidatingon the field that shifted into its path. Tests should remove the first and middle rows while validators are unresolved, resolve them in reverse order, and assert both field-level and form-level validating counters return to zero.