fix(deployment): prevent trigger registry initialization crash - #6342
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview Mock payloads move from Editor sub-block reads in trigger definitions no longer statically import CI enforcement: Reviewed by Cursor Bugbot for commit c9aa3ec. Configure here. |
Greptile SummaryThe 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.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| 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.
|
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 routeReproduced deterministically — a single import is enough: 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. They all funnel through Bisect confirms #6272
#6272 removed Production is not affectedWorth stating plainly before anyone treats this as a P0. Checked CloudWatch (
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 Why the guard was replaced rather than keptTwo problems with fixing it at the call site:
The structural fixThere were 13 static
With the cycle gone the ordering guard is unnecessary, so Bundle side effect: Guard that can actually fail
Verified it fails on the broken code by reverting one edge: Verification
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
|
@cursor review |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ 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.
2 participants
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
Reviewers should focus on the explicit registry initialization at the top of apps/sim/lib/webhooks/deploy.ts.
Checklist
Screenshots/Videos
Not applicable; this is a server-side module-initialization fix with no UI changes.