[One Workflow][Bug] Toggling workflow enabled state corrupts YAML conten#252676
[One Workflow][Bug] Toggling workflow enabled state corrupts YAML conten#252676rosomri merged 2 commits intoelastic:mainfrom
Conversation
…iption/tags) would corrupt the stored YAML. The server was performing a full YAML > JSON > YAML roundtrip just to update metadata fields
…iption/tags) would corrupt the stored YAML. The server was performing a full YAML > JSON > YAML roundtrip just to update metadata fields
💚 Build Succeeded
Metrics [docs]
|
|
Starting backport for target branches: 9.3 https://github.com/elastic/kibana/actions/runs/21904391570 |
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
9 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
25 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
The bundled YAML, the Setup wizard, and the CLI installer all set `enabled: true` on create, which made it possible for a fresh install to start running the moment a user attached it to a rule — before they had a chance to review the notification step. The user-facing design calls out three manual follow-up steps (review notification, attach to rules, enable); the third one was effectively skipped because the workflow was already enabled. Now every install path persists `enabled: false`: - workflows/data-pipeline-alert-enrichment.yaml top-level flag - assets/workflows/ mirror (regenerated by export-standalone-assets) - Bulk POST /api/workflows envelope in the wizard + CLI - Update-existing PUT path in the wizard + CLI Working around elastic/kibana#252676: Kibana 9.5's Workflows API silently drops the `enabled` field when it's sent inside a full PUT body alongside `yaml`. After the regular update, both installers now follow up with a *partial* PUT containing just `{ enabled: false }` — that path is unaffected by the bug. Verified end to end on Observability Serverless 9.5.0: PUT /api/workflows/workflow/<id> (full body) → 200, enabled: true (bug) PUT /api/workflows/workflow/<id> ({enabled: false}) → 200, enabled: false Post-install messaging in the wizard, CLI, and docs (workflow-deployment, SETUP-WIZARD-AND-UNINSTALL, SetupPage description, YAML header comment) now lists three manual steps — review notification, attach to rules, flip the Enabled toggle — and explains that the install is intentionally a no-op until all three are complete. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
2 similar comments
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Summary
Fixes a bug where toggling a workflow's
enabledstate (or updating name/description/tags) would corrupt the stored YAML. The server was performing a full YAML → JSON → YAML roundtrip just to update metadata fields, which:{{ inputs.comment }}into"{ inputs.comment }": nullBefore
Screen.Recording.2026-02-11.at.10.49.58.mov
After
Screen.Recording.2026-02-11.at.11.55.05.mov
Fix
Replaced the parse-modify-stringify approach in
workflows_management_service.tswithupdateWorkflowYamlFields(), which edits fields in-place on the YAML AST (usingparseDocumentwithkeepSourceTokens: true), preserving all comments, formatting, and template expressions.Test plan
updateYamlFieldandupdateWorkflowYamlFieldscovering comment/blank line/template expression preservationworkflows_management_service.test.tsverifying the full update flow preserves YAML integrity when toggling enabled