fix: v1.8.1 — --dry-run no longer mutates on activate/deactivate - #5
Merged
Merged
Conversation
`workflow activate` and `workflow deactivate` ignored --dry-run and performed the change anyway. Every other mutation verb (25 of them) guards on the flag, so a caller reasonably treats --dry-run as a safe way to see what a script would touch on production — `n8nctl workflow --dry-run deactivate <id>` took a live workflow offline instead. Found the hard way: running that exact command against the live instance while verifying the 1.8.0 release printed "deactivated" where "[dry-run]" was expected. No damage — the target was already inactive and updatedAt never moved — but the flag was doing the opposite of its contract. Both handlers now GET the workflow, print a [dry-run] preview (noting when it would be a no-op), and issue no write. The regression tests assert the POST is never issued, not just the wording, so the guard cannot decay into a cosmetic message change. A --dry-run that mutates is exactly the kind of bug a passing "it printed something" test would have missed. Pre-existing, not introduced by 1.7.0/1.8.0 — flagged as a LOW/out-of-scope note during the #3 review and deprioritised there, which in hindsight undersold it: the flag's whole purpose is production safety. 516 tests (+5), coverage gate green, lint/build/audit clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
workflow activateandworkflow deactivateignored--dry-runand performed thechange anyway. All 25 other mutation verbs guard on the flag, so a caller reasonably
treats
--dry-runas a safe way to see what a script would touch on production:A
--dry-runthat mutates is doing the opposite of its contract, and this is the moredamaging half: it takes a live workflow offline.
How it surfaced
Running that exact command against the live instance while verifying the 1.8.0
release — it printed
deactivatedwhere[dry-run]was expected. No damage: thetarget was already inactive and
updatedAtnever moved (still2026-05-13), confirmedbefore and after.
It is pre-existing, not introduced by 1.7.0/1.8.0. It was raised as a LOW
"out-of-scope" note during the #3 review and deprioritised there — which in hindsight
undersold it, since the flag's entire purpose is production safety.
The fix
Both handlers now GET the workflow, print a
[dry-run]preview, and issue no write:The preview flags a no-op so a dry run doesn't imply a change that wouldn't happen, and
is machine-readable under
--json("dryRun": true,"alreadyInactive": …).Tests
The regression tests assert the POST is never issued, not just the wording — a
--dry-runbug is exactly what a passing "it printed something" test would miss:516 tests (+5), coverage gate green, lint/build/audit clean. Re-verified against the
live instance:
updatedAtunchanged after the fix.🤖 Generated with Claude Code