fix(deployed-state): use deployed state for API sync and async execs, deployed state modal visual for enabled/disabled

[icecrasher321]

Summary

• Deployed API -- Async and Sync were not using Deployed State
• Enabled vs Disabled came from live block state rather than deployed state

Type of Change

• Bug fix

Testing

Tested deploying as API and running queries and making sure it wasn't using live state.

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 Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sim	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 5, 2025 10:27pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped (Inspect)			Aug 5, 2025 10:27pm

[greptile-apps]

Greptile Summary

This PR fixes a critical bug where deployed workflow APIs were incorrectly using live workflow state instead of the stable deployed state. The changes ensure that when workflows are deployed as APIs, they execute using the frozen deployed state rather than the potentially unstable live editing state.

The fix involves four key modifications:

1. New deployed state loader: Added loadDeployedWorkflowState function in db-helpers.ts that specifically fetches deployed workflow state from the database, validates deployment status, and converts it to the expected normalized format. This replaces the previous approach of loading from normalized tables which contained live changes.

2. API execution switch: Updated both the HTTP API route (/api/workflows/[id]/execute/route.ts) and Trigger.dev workflow execution task to use the new deployed state loader instead of loadWorkflowFromNormalizedTables. This ensures API consumers get consistent behavior from deployed workflows.

3. Block enabled/disabled state fix: Modified the workflow block component to conditionally determine enabled/disabled state based on preview mode. In preview mode (deployed state modals), it uses the deployed block state, while in normal mode it uses the current live state.

4. Data source identification: Enhanced the NormalizedWorkflowData interface to include a boolean flag indicating whether data comes from normalized tables or deployed state, allowing the system to distinguish between different execution contexts.

This architectural change aligns with standard deployment practices where published APIs serve stable versions, preventing API consumers from experiencing broken or inconsistent behavior when workflows are being edited in the UI. The separation ensures that live editing can continue without affecting production API behavior until explicitly redeployed.

Confidence score: 4/5

• This PR addresses a critical production issue and implements the correct architectural pattern for deployed vs live state
• Score reflects the presence of a type assertion to any without proper validation and potential error handling changes that could affect existing workflows
• Pay close attention to the error handling changes in API routes and the type assertion in db-helpers.ts

Context used:

Context - Avoid using type assertions to 'any' in TypeScript. Instead, ensure proper type definitions are used to maintain type safety. (link)

_{4 files reviewed, 2 comments}

_{Edit Code Review Bot Settings | Greptile}