fix(deployed-chat): trigger blocks should not interfere with deployed chat executions

[icecrasher321]

Description

Having a non-start trigger block like webhook, schedule broke deployed chats. This PR fixes this.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Screen.Recording.2025-07-31.at.12.03.48.PM.mov

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally and in CI (bun run test)
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules
• I have updated version numbers as needed (if needed)
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

Security Considerations:

• My changes do not introduce any new security vulnerabilities
• I have considered the security implications of my changes

[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	Jul 31, 2025 7:05pm

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Skipped (Inspect)			Jul 31, 2025 7:05pm

[greptile-apps]

Greptile Summary

This PR fixes a critical bug in deployed chat executions where trigger blocks (webhook, schedule, etc.) were causing failures. The change filters out trigger blocks from both block states and edges during chat execution, following the same pattern used in manual workflow execution.

The fix operates in two key areas within the chat execution pipeline:

1. Block State Filtering: When merging workflow states for chat execution, the code now identifies trigger blocks by checking if their category is 'triggers' and excludes them from the filtered states object that gets processed.

2. Edge Filtering: Similarly, all edges connected to trigger blocks (both incoming and outgoing) are filtered out to ensure the execution graph doesn't include any paths involving trigger blocks.

This approach makes sense architecturally because chat deployments are designed to accept direct user input and process it through functional workflow blocks, while trigger blocks are meant to initiate workflows based on external events or schedules. The separation ensures that chat executions remain stateless and predictable, processing only the core workflow logic without interference from triggering mechanisms.

The implementation reuses the existing getBlock() utility to identify block types and maintains consistency with how manual executions handle trigger block filtering, ensuring uniform behavior across different execution contexts.

Confidence score: 4/5

• This is a well-targeted bug fix that addresses a specific deployment issue with clear logic
• The fix follows established patterns in the codebase and maintains architectural consistency
• The apps/sim/app/api/chat/utils.ts file needs attention to ensure the filtering logic doesn't miss edge cases with complex workflow structures

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}