feat(deployments): make deployed state source of truth for non-manual executions + versioning

[icecrasher321]

Summary

Make deployed versions table be the source of truth for workflow state being executed by Webhooks, Schedules, API, Chat.

Script to make every workflow have a row since webhooks and schedules previously depended on live state.

High risk migration + type changes

Type of Change

• New feature

Testing

Tested manually with @aadamgough

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)

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
sim	Ready	Preview	Comment	Sep 25, 2025 3:22am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Sep 25, 2025 3:22am

[greptile-apps]

Greptile Summary

This PR introduces a comprehensive deployment versioning system that makes deployed workflow versions the single source of truth for all non-manual executions (webhooks, schedules, API calls, and chat). The core architectural change replaces the previous approach of using live workflow state or a single deployedState field with a dedicated workflow_deployment_version table that supports multiple versioned deployments.

The implementation adds:

• A new workflowDeploymentVersion table with proper indexing, foreign key constraints, and unique version constraints per workflow
• API endpoints for managing deployment versions (/deployments, /deployments/[version], /deployments/[version]/activate, /deployments/[version]/revert)
• Updated UI components to display version management capabilities, including version history, activation controls, and preview functionality
• Migration of existing workflows through a comprehensive script that creates initial deployment versions for backward compatibility

Key components modified include workflow execution engines (webhooks, schedules), deployment management UI, and database helpers. The system now ensures that automated executions use stable, versioned snapshots rather than potentially changing live state, enabling better deployment management, rollback capabilities, and consistency across all execution types. The changes maintain backward compatibility through the migration script while establishing a more robust foundation for workflow deployment management.

Confidence score: 3/5

• This PR requires careful review due to complex architectural changes affecting critical execution paths
• Score reflects the significant database schema changes, migration complexity, and potential for execution failures if deployed state is missing
• Pay close attention to migration script, deployment version creation logic, and error handling in execution engines

_{23 files reviewed, 14 comments}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

Greptile Summary

This review covers only the changes made since the last review, not the entire PR. The latest changes involve three key modifications to support deployment versioning architecture:

1. ChatDeploy Component Enhancement: Added an optional onDeployed callback prop to the ChatDeploy component. This callback is invoked after successful chat deployment and enables parent components to react to deployment completion by updating state or triggering related processes.

2. DeployModal State Management Updates: Modified the handleWorkflowPreDeploy function to always create new deployment versions regardless of current deployment state, removing the previous conditional logic that only deployed if not already deployed. Added an onDeployed callback to the ChatDeploy component that handles post-deployment state updates including refetching deployed state, fetching versions, and clearing redeployment flags.

3. Chat Execution Architecture Refactor: Refactored chat execution in utils.ts to use the deployment versions table as the authoritative source instead of the deprecated deployedState field on the workflow table. The change removes the deployedState field from database queries and replaces it with a call to loadDeployedWorkflowState() which retrieves active deployed state from the workflowDeploymentVersion table.

These changes are part of a larger architectural shift to centralize deployment state management and ensure that all non-manual executions (webhooks, schedules, API, chat) reference the same authoritative deployed state from the versions table rather than inconsistent live state.

Confidence score: 4/5

• This PR appears safe to merge with careful attention to testing
• Score reflects architectural changes that modify core deployment behavior but follow established patterns
• Pay close attention to chat execution flow and deployment state management logic

_{3 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}