Workflow persistence error

[Siddhartha-singh01]

Fixes #2424

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other:

Testing

This has been tested by manually resolving the merge conflicts with the latest staging branch and ensuring the persistence logic correctly chunks database insertions.

• Reviewers should focus on: The CHUNK_SIZE = 50 logic in saveWorkflowToNormalizedTables and the correct sequencing of loop/parallel subflow inserts. This ensures compatibility with SQLite's 999-parameter limit while incorporating recent staging improvements for edge remapping.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[cursor]

PR Summary

Medium Risk
Changes workflow persistence to write blocks/edges/subflows in multiple insert statements, which touches core save-path database logic and could affect large workflow saves if chunking or transaction behavior is incorrect.

Overview
Fixes workflow persistence failures on SQLite by chunking inserts when saving to normalized tables.

saveWorkflowToNormalizedTables now deletes existing normalized rows and then inserts blocks, edges, and subflows in batches (CHUNK_SIZE = 50) to stay under SQLite's 999 bound-parameter limit, instead of issuing single large INSERT statements. Minor formatting-only adjustments were also made in ID-regeneration code paths.

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

[vercel]

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:12am

[greptile-apps]

Greptile Summary

This PR fixes a workflow persistence error caused by SQLite's 999-bound-parameter limit by chunking INSERT statements into batches of 50 rows across workflowBlocks, workflowEdges, and workflowSubflows. All inserts remain within the same database transaction, so atomicity is preserved. The chosen chunk size (50) is safely below the per-table limit for all three tables (58 for blocks at 17 fields, 166 for edges at 6 fields, 249 for subflows at 4 fields).

• Chunked inserts in saveWorkflowToNormalizedTables (CHUNK_SIZE = 50): correct fix, all chunks execute inside the existing db.transaction wrapper
• Indentation regressions in regenerateWorkflowStateIds: two sections (// Map edge IDs block and // Regenerate edges comment) were accidentally re-indented to 4 spaces, creating visual inconsistency with the surrounding 2-space-indented code — these changes are unrelated to the fix and should be reverted
• The loadWorkflowFromNormalizedTables indentation-only changes are harmless reformatting

Confidence Score: 5/5

Safe to merge — the chunking fix is correct and all remaining findings are cosmetic indentation issues

The core logic (CHUNK_SIZE=50 batched inserts inside an existing transaction) is sound and correctly addresses the SQLite 999-parameter limit. The only open issues are two P2 indentation regressions in regenerateWorkflowStateIds that are unrelated to the bug and do not affect runtime behavior.

apps/sim/lib/workflows/persistence/utils.ts — indentation regressions at lines 822–826 and 900 in regenerateWorkflowStateIds

Important Files Changed

Filename	Overview
apps/sim/lib/workflows/persistence/utils.ts	Core fix adds CHUNK_SIZE=50 chunked inserts to avoid SQLite's 999-parameter limit for blocks (17 fields), edges (6 fields), and subflows (4 fields) within the existing transaction — logic is correct. Also includes minor indentation regressions in regenerateWorkflowStateIds unrelated to the bug fix.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[saveWorkflowToNormalizedTables] --> B[Delete existing blocks/edges/subflows]
    B --> C{blocks.length > 0?}
    C -- Yes --> D[Chunk blockInserts into groups of 50]
    D --> E[INSERT each chunk into workflowBlocks]
    C -- No --> F{edges.length > 0?}
    E --> F
    F -- Yes --> G[Chunk edgeInserts into groups of 50]
    G --> H[INSERT each chunk into workflowEdges]
    F -- No --> I[Build subflowInserts]
    H --> I
    I --> J{subflowInserts.length > 0?}
    J -- Yes --> K[Chunk subflowInserts into groups of 50]
    K --> L[INSERT each chunk into workflowSubflows]
    J -- No --> M[Done]
    L --> M
    style D fill:#d4edda,stroke:#28a745
    style G fill:#d4edda,stroke:#28a745
    style K fill:#d4edda,stroke:#28a745

Loading

_{Reviews (1): Last reviewed commit: "Merge staging into fix/workflow-persiste..." | Re-trigger Greptile}

[greptile-apps]

Inconsistent indentation introduced

The "Map edge IDs" block (comment + forEach) has been re-indented to 4 spaces, while every other statement at the same scope level uses 2-space indentation (see lines 817–820, 828–836). This makes the block visually appear nested inside the previous forEach, which it is not.

Suggested change

	// Map edge IDs
	;(state.edges || []).forEach((edge: Edge) => {
	edgeIdMapping.set(edge.id, crypto.randomUUID())
	})
	; (state.edges || []).forEach((edge: Edge) => {
	edgeIdMapping.set(edge.id, crypto.randomUUID())
	})
	// Map edge IDs
	;(state.edges || []).forEach((edge: Edge) => {
	edgeIdMapping.set(edge.id, crypto.randomUUID())
	})

[greptile-apps]

Comment indented to wrong level

This comment was shifted to 4-space indentation, but the forEach call it labels on line 902 remains at 2-space indentation. The mismatch makes the comment appear detached from the code it describes.

Suggested change

	// Regenerate edges with updated source/target references
	// Regenerate edges with updated source/target references