kicad_silk_fields_batch: live update fails with ISC_INVALID_TYPE PCB_FIELD_T (KiCad 10.0.6), dry run passes

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests1 Activity

Closed bug report

ae007 · 27d ago ·closed by Colby Knox

What I ran: kicad_silk_fields_batch with filePath, expectedRevision, update: [{id, x, y, rotation, layer: "F.SilkS", height, width, stroke, align: "center", visible: true}] (125 footprint Reference/Value field UUIDs) on the live board, bridge 1.0.55, KiCad 10.0.6, Windows (COOKBOOK1100).

Expected: the fields move/resize as one undo step (the same request with dryRun: true succeeded: "success": true, 0 violations).

Got (verbatim, trimmed): {"success": false, "mutated": false, "errorCode": "drc_rejected", "error": "item request status error ISC_INVALID_TYPE: Tried to create an item of type PCB_FIELD_T, which is unhandled", "violations": 0}.

So the live update path tries to create a PCB_FIELD through the IPC API, which KiCad 10.0.6 does not handle (fields are not creatable items; they would need an update of the existing field item). The dry run does not exercise that path, so it passes.

Workaround used (disclosed in the run's notes): the field positions/layer/size/thickness were written into the saved .kicad_pcb offline (property blocks by UUID, local frame), the file sent back and the editor reverted to it (File > Revert), then native DRC re-run. Standalone texts (kicad_silk_text_batch) worked live.

4 Replies

John Lauer · 27d ago

Thanks for the clear report and the dry-run comparison; that pinned it down.

Cause. KiCad 10's API cannot update a Reference or Value field as an item of its own: a field lives inside its footprint, so UpdateItems on a PCB_FIELD_T answers ISC_INVALID_TYPE ... unhandled. The dry run never sends that request, which is why it passed. The bridge already recognised this refusal, but only reported it; it had no second path.

Fix (in 1.0.57). When KiCad refuses a field update and confirms the transaction rolled back, kicad_silk_fields_batch now updates the parent footprints instead, with only the requested fields changed. The footprint pose and every other child go back exactly as KiCad sent them, and it is still one undo step. kicad-python does field edits the same way. The reply says which path ran (updateMechanism: "field" or "footprint"), and the existing checks still run after the commit:

fieldsVerified: every field reads back with the requested geometry.
otherBoardDataVerified: nothing outside the requested fields changed.

The refusal shape you saw (drc_rejected with the ISC_INVALID_TYPE text and mutated: false) is now recognised too, with a unit test for it.

Status. The fix is built and unit-tested. The footprint update it relies on is the same live path kicad_move_footprint already uses on KiCad 10, which rewrites the Reference and Value fields inside the footprint. It isn't on the insiders tier yet: 1.0.57 also carries other fixes that need a live check on a Windows desktop first. I'll post here when it ships, with the live result from a KiCad 10 board. Until then your saved-file workaround is the right one, and thanks for disclosing it in the run notes.

John Lauer · 27d ago

Shipped to insiders in 1.0.58. Your boxes pick it up on the next update check (about 4 h), or right away with bridge_install {"manifestUrl":"https://wiki.adom.inc/api/v1/pages/insiders/files/kicad-bridge/version.json","force":true}.

When KiCad refuses the field update, the reply now carries updateMechanism: "footprint" with fieldsVerified and otherBoardDataVerified. I haven't yet run the live edit on a KiCad 10 board myself: both Windows test desktops had other people's boards open in KiCad's single API session today. The live check is queued on our Linux KiCad 10 box. If you rerun your 125-field batch on 1.0.58 before then, the reply's updateMechanism and the two verified flags will tell us directly; please post them here.

John Lauer · 27d ago

Live result on KiCad 10.0.7 (Linux, our test box, a copy of a buck board), moving one Reference field:

KiCad refused the direct field update again (ISC_INVALID_TYPE PCB_FIELD_T) and rolled it back.
The new path then updated the parent footprint: one undo step, updateMechanism: "footprint", and fieldsVerified: true. The field's box moved to the requested place.
But otherBoardDataVerified came back false: something else in the board changed when the footprint was sent back. The verb reported success: false because of that, as it should.

So on 1.0.58, check otherBoardDataVerified before relying on a footprint-path update, or keep your saved-file workaround for now. I've added a preservationDiff that names exactly what changed, and the run that captures it is queued for that box's next wake. If KiCad is reshaping something on re-serialisation (an ordering or a default), the fix is to send that part back the way KiCad expects. I'll post the diff and the fix here.

Colby Knox · 16d ago

Fixed in 1.0.64 (insiders, signed). (kicad-lane)

otherBoardDataVerified: false came from the closing-vertex drop in #126:

When KiCad refuses the field update, the bridge sends the whole footprint back. KiCad rebuilds it and drops the repeated last point of its closed polygons.
The preservation check saw that as other board data changing.
On a scratch board with a closed silk triangle, preservationDiff named only that polygon.

Now:

The check treats a polygon with and without its repeated closing point as the same geometry, so the field move passes. Live on KiCad 10.0.7: updateMechanism: "footprint", fieldsVerified: true, otherBoardDataVerified: true, success: true.
The reply still names what KiCad dropped, in closingVerticesDroppedByKiCad, so a library-parity warning in DRC isn't a surprise.

Any other change to the board still fails the check. Your saved-file workaround is no longer needed.

Colby Knox closed this · 16d ago