Repository navigation
Conversation
Array items were passed to transformPointDataToPayload whenever
`typeof item === 'object'`, which is also true for arrays. Inner arrays were
then rebuilt via Object.entries() and turned into index-keyed objects, e.g.
[[0, 0], [1, 0]] became [{ '0': 0, '1': 0 }, { '0': 1, '1': 0 }].
This corrupts any nested array in tool input data, such as coordinate lists
stored in json fields, so MCP create/update calls either fail validation or
store the wrong shape. Map arrays recursively instead; point conversion and
null handling are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
What?
transformPointDataToPayload(used by the MCP create/update/duplicate tools and the data CLI) turns nested arrays into index-keyed objects:Why?
Array items are forwarded to
transformPointDataToPayloadwhenevertypeof item === 'object', which is also true for arrays. The inner array is then rebuilt viaObject.entries().Any nested array in tool input data is affected, e.g. coordinate or polygon lists stored in a
jsonfield. In our case, an MCPupdateof a page whose block holds a shape definition in ajsonfield failed the field's validation, while the identical data passed when written through the Local API.How?
Arrays are mapped recursively through a small
transformArrayhelper: inner arrays stay arrays, objects inside arrays still go throughtransformPointDataToPayload, primitives andnullpass through unchanged. Point conversion ({ longitude, latitude }→[longitude, latitude]) is untouched.Added
transformPointDataToPayload.spec.tscovering point conversion (top level and inside arrays), nested arrays andnull/primitive items. The two new cases fail on currentmainand pass with this change.The same code exists on
3.xinpackages/plugin-mcp/src/utils/transformPointDataToPayload.ts(we hit it on 3.85.0 and currently patch it viapnpm patch). Happy to open a backport PR against3.xif that's useful.🤖 Generated with Claude Code