fix(serializer): preserve block enabled state during deserialization by lawrence3699 · Pull Request #3950 · simstudioai/sim

lawrence3699 · 2026-04-04T22:52:33Z

Summary

The deserializer hardcodes enabled: true for regular blocks (line 625), ignoring the enabled field that was correctly saved during serialization (line 294). This causes disabled blocks to silently become re-enabled when a workflow is loaded, imported, or round-tripped through serialize/deserialize.

The loop/parallel branch at line 594 already handles this correctly with serializedBlock.enabled ?? true. This PR applies the same pattern to regular blocks.

Reproduction

Create a workflow with multiple blocks
Disable one of the blocks
Save and reload the workflow (or import/export it)
The disabled block is now enabled again

Fix

Change enabled: true → enabled: serializedBlock.enabled ?? true to match the pattern already used for loop/parallel blocks.

Test plan

Existing serializer tests continue to pass
Verify that disabling a block and reloading the workflow preserves the disabled state
Verify that workflows without an enabled field in serialized blocks default to true (backwards compatible)

…ership workflow edits via sockets, ui improvements

The deserializer hardcodes `enabled: true` for regular blocks, ignoring the `enabled` field that was correctly saved during serialization. This causes disabled blocks to silently become re-enabled when a workflow is loaded, imported, or round-tripped through serialize/deserialize. The loop/parallel branch already handles this correctly with `serializedBlock.enabled ?? true` — apply the same pattern to regular blocks.

cursor · 2026-04-04T22:52:39Z

PR Summary

Low Risk
Low risk: a one-line deserialization change that only affects whether blocks load as disabled vs enabled, with a safe default for older serialized workflows.

Overview
Fixes workflow deserialization to preserve each block’s enabled state instead of always re-enabling blocks.

Regular blocks now use enabled: serializedBlock.enabled ?? true, matching the existing loop/parallel handling and remaining backward-compatible when older serialized data omits enabled.

^{Reviewed by Cursor Bugbot for commit 5035869. Bugbot is set up for automated code reviews on this repo. Configure here.}

vercel · 2026-04-04T22:52:40Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 4, 2026 10:52pm

Copilot

Pull request overview

Fixes workflow deserialization to preserve a block’s saved enabled state instead of re-enabling regular blocks unconditionally, preventing disabled blocks from silently becoming enabled after reload/import/round-trip.

Changes:

Update regular block deserialization to use serializedBlock.enabled ?? true, matching the existing loop/parallel behavior.
Maintain backward-compatible defaulting to true when enabled is absent.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-04T22:55:13Z

apps/sim/serializer/index.ts

      position: serializedBlock.position,
      subBlocks,
      outputs: serializedBlock.outputs,
-      enabled: true,
+      enabled: serializedBlock.enabled ?? true,
      triggerMode:


This change will require updating the existing unit test that currently asserts the buggy behavior. apps/sim/serializer/tests/serializer.extended.test.ts has a case (should deserialize enabled status correctly) where enabled: false is expected to deserialize to true; after preserving enabled, it should assert false (and ideally add a separate assertion for the backward-compat default when enabled is missing).

Copilot · 2026-04-04T22:55:13Z

apps/sim/serializer/index.ts

      outputs: serializedBlock.outputs,
-      enabled: true,
+      enabled: serializedBlock.enabled ?? true,
      triggerMode:


SerializedBlock.enabled is currently typed as a required boolean (apps/sim/serializer/types.ts), but deserialization now treats it as optional via serializedBlock.enabled ?? true for backward compatibility. Consider updating the SerializedBlock type (or introducing a versioned/migrated type) so the TypeScript types match the actual data shape coming from persisted workflows.

greptile-apps · 2026-04-04T22:58:00Z

Greptile Summary

This PR fixes a silent state-loss bug in the workflow deserializer where regular blocks always came back as enabled: true regardless of their saved state, causing disabled blocks to be silently re-enabled on every workflow load, import, or round-trip.

Root cause: deserializeBlock (line 625) hardcoded enabled: true for all non-loop/parallel blocks, while the serializer (line 294) correctly saved block.enabled.
Fix: Replaces enabled: true with enabled: serializedBlock.enabled ?? true, identical to the pattern already used for loop/parallel blocks at line 594.
Backwards compatibility: The ?? true fallback ensures older serialized workflows without an enabled field default to true, preserving existing behaviour.
Test coverage: No existing automated test exercises deserialization of a disabled regular block; a regression test would strengthen the fix (see inline comment).

Confidence Score: 5/5

Safe to merge — the one-line fix is unambiguously correct and carries no regression risk.

The change mirrors the exact pattern already in use for loop/parallel blocks at line 594, the serialization side (line 294) already persists the field, and the ?? true default preserves backwards compatibility. The only finding is a P2 suggestion to add a regression test, which does not block merge.

No files require special attention; the single changed line in apps/sim/serializer/index.ts is straightforward.

Important Files Changed

Filename	Overview
apps/sim/serializer/index.ts	One-line fix: replaces hardcoded `enabled: true` with `serializedBlock.enabled ?? true` at line 625, preserving disabled block state during deserialization and matching the existing loop/parallel pattern at line 594

Sequence Diagram

sequenceDiagram
    participant UI as Workflow UI
    participant S as Serializer

    Note over UI,S: Save / Export
    UI->>S: serializeWorkflow(blocks)
    S-->>UI: SerializedBlock { enabled: false }

    Note over UI,S: Load / Import — Before Fix
    UI->>S: deserializeWorkflow(serialized)
    S-->>UI: BlockState { enabled: true } ❌ hardcoded

    Note over UI,S: Load / Import — After Fix
    UI->>S: deserializeWorkflow(serialized)
    S->>S: serializedBlock.enabled ?? true
    S-->>UI: BlockState { enabled: false } ✅ preserved

Comments Outside Diff (1)

apps/sim/serializer/index.test.ts, line 248-249 (link)

Missing regression test for disabled block round-trip

The PR's own test plan calls out "Verify that disabling a block and reloading the workflow preserves the disabled state", but no automated test covers this path. All existing deserializeWorkflow tests create blocks with enabled: true, so the bug fixed by this PR would not have been caught by the current suite.

Consider adding a test inside the deserializeWorkflow describe block:

it.concurrent('should preserve disabled state of a regular block through deserialization', () => {
  const { blocks, edges, loops } = createComplexWorkflowState()
  // Disable a regular block before serializing
  blocks.function1 = { ...blocks.function1, enabled: false }
  const serializer = new Serializer()

  const serialized = serializer.serializeWorkflow(blocks, edges, loops)
  const deserialized = serializer.deserializeWorkflow(serialized)

  expect(deserialized.blocks.function1.enabled).toBe(false)
  // Enabled blocks should remain enabled
  expect(deserialized.blocks.api1.enabled).toBe(true)
})

This would serve as a regression guard for the bug fixed here and satisfy the manual verification step in the test plan.

_{Reviews (1): Last reviewed commit: "fix(serializer): preserve block enabled ..." | Re-trigger Greptile}

gitguardian · 2026-04-09T00:41:07Z

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
29606901	Triggered	Generic High Entropy Secret	`a54dcbe`	apps/sim/providers/utils.test.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

Understand the implications of revoking this secret by investigating where it is used in your code.
Replace and store your secret safely. Learn here the best practices.
Revoke and rotate this secret.
If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

following these best practices for managing and storing secrets including API keys and other credentials
install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

waleedlatif1 and others added 3 commits April 3, 2026 23:30

v0.6.23: MCP fixes, remove local state in favor of server state, moth…

0b9019d

…ership workflow edits via sockets, ui improvements

v0.6.24: copilot feedback wiring, captcha fixes

a54dcbe

Copilot AI review requested due to automatic review settings April 4, 2026 22:52

vercel bot temporarily deployed to Preview April 4, 2026 22:52 Inactive

Copilot started reviewing on behalf of lawrence3699 April 4, 2026 22:53 View session

Copilot AI reviewed Apr 4, 2026

View reviewed changes

icecrasher321 changed the base branch from main to staging April 9, 2026 00:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(serializer): preserve block enabled state during deserialization#3950

fix(serializer): preserve block enabled state during deserialization#3950
lawrence3699 wants to merge 3 commits intosimstudioai:stagingfrom
lawrence3699:fix/deserializer-preserve-block-enabled-state

lawrence3699 commented Apr 4, 2026

Uh oh!

cursor bot commented Apr 4, 2026 •

edited

Loading

Uh oh!

vercel bot commented Apr 4, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 4, 2026

Uh oh!

Copilot AI Apr 4, 2026

Uh oh!

greptile-apps bot commented Apr 4, 2026 •

edited

Loading

Comments Outside Diff (1)

Uh oh!

gitguardian bot commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

lawrence3699 commented Apr 4, 2026

Summary

Reproduction

Fix

Test plan

Uh oh!

cursor bot commented Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

vercel bot commented Apr 4, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 4, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 4, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Sequence Diagram

Comments Outside Diff (1)

Uh oh!

gitguardian bot commented Apr 9, 2026

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cursor bot commented Apr 4, 2026 •

edited

Loading

greptile-apps bot commented Apr 4, 2026 •

edited

Loading