fix(deploy): keep ignoring the error flag's old home in block data

Deploying never converged: the badge asked to redeploy again the moment it
finished, forever.

The flag lived in `data` before it had a column. `0287` moves it, but a migration
only reaches the live tables — every deployment version already written is frozen
jsonb that keeps the old key. The wire schema no longer declares it either, so Zod
strips it from the live state on its way to the client. So the two sides of the
check genuinely differ: live `data: {}` against a snapshot's
`data: {errorEnabled: false}`, reported as `data.errorEnabled` changed. Deploying
cannot fix that — the next snapshot is taken from rows that still carry the key.

Confirmed against a real stuck workflow: 18 versions, both blocks reporting
`data.errorEnabled`, and the same two states comparing equal with this restored.

Removing the exclusion in 7934df7 assumed the migration could reach every copy
of the value. It cannot reach a frozen snapshot, so the comparison has to keep
tolerating the old key regardless of where it survives. The block field is still
compared on its own, with `!!`, so the flag itself is not ignored.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Vikhyath Mondreti

apps/sim/lib/workflows/comparison/compare.test.ts

@@ -388,6 +388,33 @@ describe('hasWorkflowChanged', () => {
     })
   })
 
+  /**
+   * The flag lived in `data` before it had a column. `0287` moves it, but a migration
+   * only reaches the live tables — every deployment version already written is frozen
+   * jsonb that keeps the old key, and the wire schema no longer declares it, so Zod
+   * strips it from the live side. Compared, that read as a change no deploy could
+   * resolve: the next snapshot came from rows that still carried it.
+   */
+  describe('Legacy error flag in block data', () => {
+    const withData = (data: Record<string, unknown>) =>
+      createWorkflowState({ blocks: { block1: createBlock('block1', { data }) } })
+
+    it.concurrent('ignores the flag wherever the old key survives', () => {
+      expect(hasWorkflowChanged(withData({}), withData({ errorEnabled: false }))).toBe(false)
+      expect(hasWorkflowChanged(withData({}), withData({ errorEnabled: true }))).toBe(false)
+    })
+
+    it.concurrent('still compares everything else in data', () => {
+      expect(
+        hasWorkflowChanged(
+          withData({ errorEnabled: false }),
+          withData({ errorEnabled: false, parallelType: 'count' })
+        )
+      ).toBe(false)
+      expect(hasWorkflowChanged(withData({ batchSize: 1 }), withData({ batchSize: 2 }))).toBe(true)
+    })
+  })
+
   describe('SubBlock Changes', () => {
     it.concurrent('should detect subBlock value changes (string)', () => {
       const state1 = createWorkflowState({

apps/sim/lib/workflows/comparison/normalize.ts

@@ -51,6 +51,18 @@ export const EXCLUDED_BLOCK_DATA_FIELDS: readonly string[] = [
   // Parallel fields - duplicated in parallels state and/or subBlocks
   'parallelType', // Duplicated in parallels state
   'distribution', // Parallel distribution (derived during execution)
+
+  /*
+   * Duplicated from the block's own `errorEnabled`. The flag briefly persisted
+   * here before it had a column, and `0287` moves it — but a migration only
+   * reaches the live tables. Every deployment version ever written is frozen
+   * jsonb that keeps the old key forever, and the wire schema no longer declares
+   * it, so Zod strips it from the live side while the snapshot side keeps it.
+   * Compared, that reads as a change no deploy can resolve: the next snapshot is
+   * taken from rows that still carry the key. The block field is compared on its
+   * own, with `!!`, so the value itself is not lost here.
+   */
+  'errorEnabled',
 ] as const
 
 /**