fix(control-plane): clear mental-model tags when the edit field is emptied (#2507)

[nicolas-vivot]

Summary

Fixes #2507. In the control-plane mental-model edit dialog, emptying the tags field and saving did not clear the tags — the old tags persisted, and refreshes kept filtering by them. The only workaround was to delete and recreate the mental model.

Root cause

UpdateMentalModelDialog.handleUpdate built the PATCH payload as:

tags: tags.length > 0 ? tags : undefined,

When the field is emptied, tags is [], so this sends undefined. JSON.stringify drops undefined keys, so the PATCH body arrives at the dataplane with no tags field. The dataplane update path treats an absent field as "leave unchanged" (if tags is not None: in update_mental_model), so the previously stored tags are kept. This matches the reported symptom exactly.

Note the dataplane already clears correctly when it receives tags: []; the bug was purely the client omitting the field.

Fix

Send the tags array unconditionally, including the empty array:

tags,

Now emptying the field sends tags: [], and the backend clears the tags.

Why this approach

• tags here is always a string[] (built via split/map/filter), never null/undefined — so the change affects only the empty case. Every non-empty case is byte-for-byte identical to before.
• No accidental clearing: the form is seeded from mentalModel.tags and re-seeded on open / model change, so saving without touching tags re-sends the existing tags, not an empty list.

Scope

Limited to the flat tags field, as reported. The same ? … : undefined pattern exists for the trigger fields in this form, so clearing those via the UI may have the same class of issue — deliberately left out of this fix and can be tracked separately.

The create dialog keeps tags.length > 0 ? tags : undefined, which is correct there: create has no prior state and the server coerces [] → None anyway.

Tests

No test was added or updated:

• No existing test references this component, the UpdateMentalModelDialog, or the updateMentalModel client method, so there is nothing to update.
• The control-plane test suite runs under vitest with environment: "node" and no DOM testing tooling (@testing-library, jsdom/happy-dom). There is no harness today that renders the dialog and asserts on the emptied-field → tags: [] behavior, which is where the bug lives.
• Adding a full component-test harness (new dev-deps + DOM environment) is disproportionate for a one-line change. The fix was validated by tracing the full request path; the behavior is straightforward to confirm manually in the UI.

If maintainers prefer, a lightweight client-level contract test (assert the PATCH body carries tags: []) or a new component-test harness can be added as a follow-up.

🤖 Generated with Claude Code