fix: mark timeSavedMode as derived to prevent 400 on workflow writes (n8n >= 2.33)

[LouisBurette]

Problem

On n8n instances >= 2.33.0, every write operation (n8n_update_partial_workflow, n8n_update_full_workflow) fails with:

400 Invalid request: request/body/settings must NOT have additional properties

Root cause

n8n 2.33.0 added timeSavedMode to the workflowSettings DB column and echoes it back on GET /workflows/{id}. However, the public API PUT schema (additionalProperties: false) does not list timeSavedMode as an accepted property — so it rejects it on write.

binaryMode and credentialResolverId, introduced in the same release, already carry derived: true in WORKFLOW_SETTINGS_PROPERTIES and are correctly stripped by stripDerivedSettings() before every PUT. timeSavedMode was missing the flag by oversight.

Fix

One-word change in src/constants/workflow-settings.ts:

// before
timeSavedMode: { since: v(2, 33, 0) },

// after
timeSavedMode: { since: v(2, 33, 0), derived: true },

stripDerivedSettings() runs unconditionally before every write, so this is enough — no other code needs to change.

Verification

Confirmed on a live n8n 2.33+ instance (Railway-hosted):

PUT body	Result
settings includes timeSavedMode	400 request/body/settings must NOT have additional properties
settings without timeSavedMode	200 OK

The live instance's GET /api/v1/openapi.yml also confirms timeSavedMode is absent from components.schemas.workflowSettings.

Note

timeSavedMode is derived server-side (n8n sets it from internal defaults, not from the PUT body), so stripping it loses nothing — identical to the existing treatment of binaryMode.

[jusched]

Thanks for digging into this, root cause matches what I independently found this week on my own instance (n8n on Railway, n8n-mcp 2.73.0).

One data point that complicates the fix, though: binaryMode is failing the same way timeSavedMode is, on a version where it's supposedly already flagged derived: true and stripped. Wanted to flag it here in case #1017 alone doesn't fully resolve this class of bug for everyone.

What I tested:

Real writes against 26 workflows on my instance, ranging 1–265 nodes:
Workflows that contained "binaryMode" in its settings, 26/26 failures. (400: request/body/settings must NOT have additional properties)

When binaryMode was stripped, 26/26 succeeded.

Critically, this isn't just a raw-API finding, the identical error reproduced through n8n_update_partial_workflow itself, on a plain addNode operation that never touched settings. So whatever stripDerivedSettings() is supposed to be doing for binaryMode on this version, it isn't happening in practice.

Hypothesis: the registry entries are version-gated (since: v(2, 33, 0)), and n8n's public API stopped exposing its own version starting 1.119.0. If n8n-mcp can't reliably detect the connected instance is ≥2.33.0, none of the version-gated derived entries, including the ones that are supposedly already correct, would ever activate. Could explain why binaryMode behaves like it was never flagged, despite the registry saying otherwise.

Happy to share full request/response logs or a repro script if that'd help narrow it down. Might be worth this PR (or a follow-up) also confirming binaryMode/credentialResolverId are actually being stripped at runtime on a 2.33+ instance, not just checking the registry definition.

[czlonkowski]

Thanks @LouisBurette and @jusched, the investigation was right about the symptom but the fix needed a different shape. Checked live against n8n 2.36.7: PUT accepts and echoes timeSavedMode (it validates the value against fixed/dynamic), so marking it derived would drop a real setting on current instances; the 400 you saw comes from an n8n whose write schema lagged its entity. #1059 instead retries a rejected write without the settings keys the instance does not accept (unknown keys first, then known ones newest first) and reports what it left out in the response warnings, verified live with a create and a partial update carrying an unknown key. binaryMode is stripped unconditionally on main since v2.70.0; if it still reaches PUT for you on a current release, please open an issue with the request body and n8n version. Closing this one in favour of #1059; you are both credited there.