fix(deployment): prevent trigger registry initialization crash by BillLeoutsakosvl346 · Pull Request #6342 · simstudioai/sim

BillLeoutsakosvl346 · 2026-08-06T21:03:07Z

Summary

Fixes workflow deployment requests that crash while initializing the trigger registry.

PR #6272 made the deploy path import the trigger barrel before the block registry. Trigger definitions reference block configs during module initialization, which allowed the trigger barrel to be re-entered before TRIGGER_REGISTRY was ready. This change explicitly initializes the block registry first and preserves the existing deployment behavior.

Type of Change

Testing

bun run test -- lib/webhooks/deploy.test.ts triggers/webhook-url.test.ts (29 passed)
bunx biome check apps/sim/lib/webhooks/deploy.ts
bun run check:api-validation
Clean Next.js compilation of POST /api/workflows/:id/deploy reaches authentication and returns the expected 401 without a session instead of the TRIGGER_REGISTRY 500

Reviewers should focus on the explicit registry initialization at the top of apps/sim/lib/webhooks/deploy.ts.

Checklist

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

Screenshots/Videos

Not applicable; this is a server-side module-initialization fix with no UI changes.

vercel · 2026-08-06T21:03:13Z

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

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 6, 2026 10:01pm

cursor · 2026-08-06T21:03:18Z

PR Summary

Medium Risk
Touches core trigger/block registry initialization order and many trigger fetchOptions paths; behavior should match prior store reads but async dynamic imports add a new failure surface if stores load late.

Overview
Breaks the triggers ↔ blocks module initialization cycle that can throw ReferenceError: Cannot access 'TRIGGER_REGISTRY' before initialization when @/triggers is evaluated before @/blocks (e.g. deploy paths that no longer accidentally import blocks first).

Mock payloads move from trigger-utils into dependency-free mock-payload.ts; @/triggers/index imports that module instead of trigger-utils, so the trigger barrel no longer pulls in code that statically depends on @/blocks.

Editor sub-block reads in trigger definitions no longer statically import useSubBlockStore / workflow registry stores (which transitively reach @/blocks). New triggers/editor-state.ts exposes async helpers that dynamic import() the stores and workflow option fetchers at call time, used across Gmail/HubSpot/IMAP/Outlook/Webflow/ClickUp/table/sim workspace triggers.

CI enforcement: scripts/check-trigger-block-cycle.ts walks static import graphs from triggers/index.ts and triggers/registry.ts and fails if blocks/ is reachable; wired as bun run check:trigger-block-cycle in CI and root package.json.

^{Reviewed by Cursor Bugbot for commit c9aa3ec. Configure here.}

greptile-apps · 2026-08-06T21:05:12Z

Greptile Summary

The PR removes the trigger registry’s static dependency path back through block-aware editor utilities, moving editor-state access behind call-time imports and adding a CI audit to prevent the initialization cycle from returning.

Extracts dependency-free mock-payload generation for use by the trigger registry.
Replaces trigger option resolvers’ static Zustand-store imports with asynchronous editor-state readers.
Adds a trigger-to-block static dependency graph check to package scripts and CI.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
apps/sim/triggers/editor-state.ts	Introduces call-time editor-state readers so trigger definition evaluation no longer statically loads block-dependent stores.
apps/sim/triggers/index.ts	Redirects sample-payload generation to the new dependency-free module, removing the registry’s static path through trigger utilities.
apps/sim/lib/workflows/triggers/mock-payload.ts	Preserves mock-payload generation behavior in a module that does not depend on blocks or trigger utilities.
scripts/check-trigger-block-cycle.ts	Adds a static reachability audit that detects value-import paths from trigger registry entrypoints into block modules.
apps/sim/triggers/table/poller.ts	Migrates table option resolution to asynchronous editor-state helpers while preserving its table lookup behavior.
.github/workflows/test-build.yml	Runs the new trigger/block initialization-cycle audit in CI.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
Deploy[Deployment import] --> Triggers[Trigger registry]
Triggers --> Mock[Dependency-free mock payload]
Triggers --> Definitions[Trigger definitions]
Definitions -. option resolver invocation .-> EditorState[Dynamic editor-state imports]
EditorState --> Stores[Workflow and sub-block stores]
Stores --> Blocks[Block registry]
Audit[CI cycle audit] --> Triggers
Audit --> Definitions

_{Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/sta..." | Re-trigger Greptile}

Replaces the import-order guard from the previous commit with the structural fix. Block configs spread `getTrigger('...').subBlocks` while their module body runs, so `blocks/*` depends on `triggers/*` by design. Thirteen edges closed the loop back the other way, which made module evaluation order load-bearing: enter the graph through `@/triggers` and a block config calls `getTrigger()` before `TRIGGER_REGISTRY` is initialized, throwing ReferenceError: Cannot access 'TRIGGER_REGISTRY' before initialization Eleven deployment routes crashed on import: `POST /api/workflows/[id]/deploy`, the v1 public and admin deploy/rollback/activate routes, both deployment-version routes, and the three custom-tool deployment routes. All of them funnel through `lib/webhooks/deploy.ts`, which stayed safe only because it imported a value from `@/blocks` — biome sorts that above `@/triggers`, so the safe barrel always evaluated first. #6272 deleted that import as unused cleanup and took the whole surface with it. The reverse edges came from two places, both layering violations rather than anything inherent to triggers: - `triggers/index.ts` imported the mock-payload generator from `trigger-utils`, which imports `@/blocks` for unrelated helpers. The generator is pure, so it moves to `lib/workflows/triggers/mock-payload.ts` and both callers import it there. - Eleven trigger modules statically imported the editor's Zustand stores to read sub-block values inside `fetchOptions`/`fetchOptionById`. Those reads now go through `triggers/editor-state.ts`, which loads the stores with a dynamic `import()` — resolved when the resolver is called, not during module evaluation, so it carries no initialization-order obligation. Side effect: `@/triggers` drops from 744 statically reachable modules to 526. The block registry, the workflow Zustand stores and their React Query graph are no longer pulled into every server module that imports a trigger. `scripts/check-trigger-block-cycle.ts` fails the build if a static edge returns, and reports the shortest offending chain. The existing suite could not have caught this — `deploy.test.ts` mocks both `@/blocks/registry` and `@/triggers`, and `vitest.setup.ts` mocks `@/blocks/registry` globally, so it passed 18/18 against the broken code.

waleedlatif1 · 2026-08-06T21:54:17Z

Investigated this in depth and pushed a follow-up commit that replaces the import-order guard with the structural fix. Summary of what I found, since some of it changes how the PR should be read.

The bug is real, and it is wider than one route

Reproduced deterministically — a single import is enough:

$ bun -e "import('@/triggers')"
ReferenceError: Cannot access 'TRIGGER_REGISTRY' before initialization
at getTrigger (apps/sim/triggers/index.ts:71:19)
at apps/sim/blocks/blocks/airtable.ts:294:8

I wrote an ESM evaluation-order simulator, validated it against runtime results, ran it over 2,961 modules, then empirically probed all 1,007 API routes under Bun. Both agree exactly: 11 routes, not one.

app/api/workflows/[id]/deploy <- editor "Deploy"
app/api/workflows/[id]/deployments/[version] (GET)
app/api/workflows/[id]/deployments/[version]/revert
app/api/v1/workflows/[id]/deploy
app/api/v1/workflows/[id]/rollback
app/api/v1/admin/workflows/[id]
app/api/v1/admin/workflows/[id]/deploy
app/api/v1/admin/workflows/[id]/versions/[versionId]/activate
app/api/tools/deployments/deploy | promote | undeploy

They all funnel through lib/webhooks/deploy.ts, so the original one-line guard did fix all 11.

Bisect confirms #6272

`deploy.ts` at	result
`6cc25f6d9^` (pre-#6272)	imports fine
`6cc25f6d9` -> staging	`ReferenceError`

#6272 removed import { getBlock } from '@/blocks' as unused cleanup. Biome sorts @/blocks/* above @/triggers/*, so that import was silently guaranteeing the safe barrel evaluated first. The underlying cycle is much older (triggers/index -> trigger-utils dates to #2160, 2025-12-02) — #6272 only removed the accident hiding it.

Production is not affected

Worth stating plainly before anyone treats this as a P0. Checked CloudWatch (/ecs/sim-production/us-east-1/app) on an image built after #6272 landed on main:

POST to deploy paths in the last 22h: 211x 200, 2x 400, 0x 5xx
Zero hits for before initialization / TRIGGER_REGISTRY over Aug 4-6, in production or staging

So the crash fires under Bun's ESM loader and (per the PR description) Next dev, but the production webpack build happens to order the modules favourably. That is exactly the fragility blocks/registry.ts already documents in its anyPreviewBlocks comment: "It only worked under Turbopack because that bundler happened to order the modules favourably, which is not a guarantee to build on." Same trap, second time.

Why the guard was replaced rather than kept

Two problems with fixing it at the call site:

It is invisible to the test suite.deploy.test.ts passes 18/18 against the broken code — I ran it on unpatched staging. It does vi.mock('@/triggers') and vi.mock('@/blocks/registry'), and vitest.setup.ts:114 mocks @/blocks/registry globally anyway. The "29 passed" in the PR description is not evidence about this bug, and no test could have been added that would fail.
It is one cleanup away from breaking again — a bare side-effect import 40 lines from the import it protects, which is precisely how it broke the first time.

The structural fix

There were 13 static triggers/ -> blocks/ edges, not one. I found them by cutting them one at a time and watching the next appear, then enumerated them properly. Two causes, both layering violations:

triggers/index.ts imported the mock-payload generator from trigger-utils, which imports @/blocks for unrelated helpers. The generator is pure, so it moved to lib/workflows/triggers/mock-payload.ts.
Eleven trigger modules (gmail/outlook/hubspot/imap/table pollers, four webflow triggers, clickup/subblocks, sim/workspace-event) statically imported the editor's Zustand stores to read sub-block values inside fetchOptions/fetchOptionById. Those now go through triggers/editor-state.ts, which loads the stores with a dynamic import() — resolved when the resolver runs, not during module evaluation, so it carries no ordering obligation. Every call site was already async.

With the cycle gone the ordering guard is unnecessary, so deploy.ts is back to its #6272 state.

Bundle side effect:@/triggers drops from 744 statically reachable modules to 526. The block registry, the workflow Zustand stores and their React Query graph are no longer dragged into every server module that imports a trigger.

Guard that can actually fail

scripts/check-trigger-block-cycle.ts (wired into check:trigger-block-cycle and CI) walks static import + re-export edges from both trigger barrels and fails on any path into blocks/, printing the shortest chain. Dynamic import() is deliberately not walked — it does not participate in initialization order.

Verified it fails on the broken code by reverting one edge:

✗ triggers/index.ts can statically reach blocks/:
triggers/index.ts
-> lib/workflows/triggers/trigger-utils.ts
-> blocks/index.ts

Verification

All 1,007 API routes probed under Bun: 0 crashes (was 11)
ESM simulator over 2,961 modules: 0 (was 15)
bunx tsc --noEmit: 0 errors
vitest run triggers/ lib/workflows/triggers/ stores/workflows/: 237 passed
deploy.test.ts + webhook-url.test.ts + workspace-event.test.ts: 47 passed
check:trigger-block-cycle, check:client-boundary, check:tool-registry-boundary, check:utils, check:api-validation: pass

Not verified: the editor dropdowns whose resolvers changed (Gmail labels, Outlook folders, HubSpot properties/pipelines, IMAP mailboxes, Webflow sites/collections, ClickUp workspaces, table columns, Sim workspace-event workflow picker). The reads are behaviour-preserving and typecheck, but they are UI callbacks I have not exercised in a browser — worth a click-through before merge.

…-registry-cycle # Conflicts: # package.json

waleedlatif1 · 2026-08-06T21:55:52Z

@greptile

waleedlatif1 · 2026-08-06T21:55:57Z

@cursor review

cursor

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit c9aa3ec. Configure here.}

fix(deployment): initialize block registry before triggers
7b89646

waleedlatif1 requested a review from a team as a code owner August 6, 2026 21:53

Merge remote-tracking branch 'origin/staging' into fix/deploy-trigger…
c9aa3ec
…-registry-cycle # Conflicts: # package.json

cursorBot reviewed Aug 6, 2026
View reviewed changes

vercelBotdeployed to Preview August 6, 2026 22:01 View deployment

waleedlatif1 merged commit b04fee8 into stagingAug 6, 2026
7 checks passed

waleedlatif1 deleted the fix/deploy-trigger-registry-cycle branch August 6, 2026 22:02

This was referenced Aug 6, 2026
fix(utils): drop the .js specifiers Turbopack cannot resolve #6351
Merged
v0.7.62: file handling, mothership async runs, heic support, file hardening, general ui improvements #6366
Merged

Navigation Menu

Uh oh!

fix(deployment): prevent trigger registry initialization crash - #6342

fix(deployment): prevent trigger registry initialization crash#6342
waleedlatif1 merged 3 commits into
stagingfrom
fix/deploy-trigger-registry-cycle

BillLeoutsakosvl346 commented Aug 6, 2026

Uh oh!

vercelBot commented Aug 6, 2026•
edited
Loading

Uh oh!

cursorBot commented Aug 6, 2026•
edited
Loading

Uh oh!

greptile-appsBot commented Aug 6, 2026•
edited
Loading

Important Files Changed

Flowchart

Uh oh!

waleedlatif1 commented Aug 6, 2026

Uh oh!

waleedlatif1 commented Aug 6, 2026

Uh oh!

waleedlatif1 commented Aug 6, 2026

Uh oh!

cursorBot left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

BillLeoutsakosvl346 commented Aug 6, 2026

Summary

Type of Change

Testing

Checklist

Screenshots/Videos

Uh oh!

vercelBot commented Aug 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cursorBot commented Aug 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

greptile-appsBot commented Aug 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

waleedlatif1 commented Aug 6, 2026

The bug is real, and it is wider than one route

Bisect confirms #6272

Production is not affected

Why the guard was replaced rather than kept

The structural fix

Guard that can actually fail

Verification

Uh oh!

waleedlatif1 commented Aug 6, 2026

Uh oh!

waleedlatif1 commented Aug 6, 2026

Uh oh!

cursorBot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vercelBot commented Aug 6, 2026•
edited
Loading

cursorBot commented Aug 6, 2026•
edited
Loading

greptile-appsBot commented Aug 6, 2026•
edited
Loading