Drag-and-drop reorder fails for array items with an all-numeric _key

[skezo]

Describe the bug

Drag-and-drop reorder fails for an array item whose _key is all digits, like 342330179449. Other items in the same array reorder fine. The console shows Uncaught Error: Found no matching array element to replace.

It looks like an all-numeric _key gets decoded as an array index. getArrayItemKeyAndParentPath reads the path as sections[342330179449] instead of sections[_key=="342330179449"], so hasExplicitKey is false and the reorder runs remove(~~"342330179449"). That truncates to -1267204231, which matches nothing, so it throws.

This happens with no custom setup, because @sanity/util's randomKey is hex and about 0.5% of 12 character keys come out all digits. Any array item that happens to get one can no longer be reordered.

To Reproduce

1. Give an array item an all-digit _key, e.g. "123456789012" (or keep adding items until Studio generates one).
2. Render it with createDataAttribute(['arrayField', { _key }]) and enable drag-and-drop.
3. Drag it to a new position.
4. The console throws Found no matching array element to replace and the order does not change.

Items whose _key has at least one letter reorder normally.

Expected behavior

An all-numeric _key should be treated as a key, not an array index, so reorder works the same as for any other key.

Screenshots

n/a

Which versions of Sanity are you using?

@sanity/visual-editing 5.4.3, sanity 5.29.0

What operating system are you using?

Not environment specific (the bug is in the path decoder logic).

Which versions of Node.js / npm are you running?

Not environment specific.

Additional context

For now we work around it by never generating all-numeric _keys and re-keying existing ones. Raising it because Studio can produce these keys via randomKey, so the key generator and the overlay disagree on what a numeric segment means.

[voidhrithik]

The key is lost before getArrayItemKeyAndParentPath runs. pathToUrlString writes an index and a _key the same way, so sections[_key=="342330179449"] goes out as sections:342330179449, and coming back RE_SEGMENT_WITH_INDEX matches any run of digits and gets tested first. You get a number, and hasExplicitKey is false from there.

Leading zeros already survive, since the pattern is (0|[1-9][0-9]*).

The 0.5% is nearer 0.36%, about one in 281. (10/16)^12 for a 12 character hex key.

Put up #3564, one quantifier on the index regex.