uncaged/workflow
10
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

bug: bundle build & register workflow broken for monorepo bundle-entry #206

New Issue
Closed
opened 2026-05-12 02:49:44 +00:00 by xiaoju · 1 comment
xiaoju commented 2026-05-12 02:49:44 +00:00
Owner
Copy Link
Copy Source

Problem

There are two related issues blocking workflow add from working with the current monorepo bundle-entry files:

1. Bundle entry files use @uncaged/* package imports but bun can't resolve them

packages/workflow-template-*/bundle-entry.ts import from @uncaged/workflow-agent-hermes, @uncaged/workflow-execute, etc. But:

  • These packages aren't in the template's package.json dependencies
  • bun workspace doesn't create symlinks for them in node_modules/
  • bun build fails with Cannot find module

Current workaround: Create a separate entry file at repo root using relative paths (./packages/workflow-agent-hermes/src/index.js), but this duplicates the bundle-entry logic.

2. workflowAsAgent crashes worker when child bundle has requireEnv at top level

When solve-issue workflow's developer role calls workflowAsAgent('develop'):

  1. extractBundleExports() does import(bundlePath) on the develop bundle
  2. The develop bundle's top-level requireEnv('WORKFLOW_LLM_API_KEY') throws if the env var isn't set
  3. This should be caught by extractBundleExports's try/catch and return an error string
  4. But the worker process appears to crash silently instead of gracefully handling the error

Even when WORKFLOW_LLM_API_KEY IS set (passed via env to the thread run command), the worker that was spawned may not have it because workers are persistent — a stale worker from a previous run (without the env var) gets reused.

3. Bundle validator was too strict (FIXED in PR #203)

  • bindingInitializerIsCallable didn't accept Identifier type (var run = wf)
  • Import allowlist was exact-match only, didn't include @uncaged/workflow-agent-*, @uncaged/workflow-execute, etc.
  • Fixed: accept Identifier, use startsWith('@uncaged/workflow') wildcard

Expected behavior

cd ~/repos/workflow
bun build packages/workflow-template-solve-issue/bundle-entry.ts --bundle --format esm ...
uncaged-workflow workflow add solve-issue dist/solve-issue.esm.js

Should just work without manual workarounds.

Proposed fixes

  1. Bundle build: Add a scripts/build-bundles.sh (or bun script) that builds both bundles correctly — either by adding missing deps to template package.json, or by using a repo-root entry approach
  2. Worker env inheritance: Workers should either restart when env changes, or workflowAsAgent should handle requireEnv failures gracefully
  3. requireEnv at top level: Consider making bundle top-level code lazy (factory pattern) so import() doesn't throw

Ref: discovered during Merkle call stack Phase 3 validation (#194, #197)

## Problem There are two related issues blocking `workflow add` from working with the current monorepo bundle-entry files: ### 1. Bundle entry files use `@uncaged/*` package imports but bun can't resolve them `packages/workflow-template-*/bundle-entry.ts` import from `@uncaged/workflow-agent-hermes`, `@uncaged/workflow-execute`, etc. But: - These packages aren't in the template's `package.json` dependencies - bun workspace doesn't create symlinks for them in `node_modules/` - `bun build` fails with `Cannot find module` **Current workaround**: Create a separate entry file at repo root using relative paths (`./packages/workflow-agent-hermes/src/index.js`), but this duplicates the bundle-entry logic. ### 2. `workflowAsAgent` crashes worker when child bundle has `requireEnv` at top level When `solve-issue` workflow's developer role calls `workflowAsAgent('develop')`: 1. `extractBundleExports()` does `import(bundlePath)` on the develop bundle 2. The develop bundle's top-level `requireEnv('WORKFLOW_LLM_API_KEY')` throws if the env var isn't set 3. This should be caught by `extractBundleExports`'s try/catch and return an error string 4. But the worker process appears to crash silently instead of gracefully handling the error Even when `WORKFLOW_LLM_API_KEY` IS set (passed via env to the thread run command), the worker that was spawned may not have it because workers are persistent — a stale worker from a previous run (without the env var) gets reused. ### 3. Bundle validator was too strict (FIXED in PR #203) - `bindingInitializerIsCallable` didn't accept `Identifier` type (`var run = wf`) - Import allowlist was exact-match only, didn't include `@uncaged/workflow-agent-*`, `@uncaged/workflow-execute`, etc. - Fixed: accept Identifier, use `startsWith('@uncaged/workflow')` wildcard ## Expected behavior ```bash cd ~/repos/workflow bun build packages/workflow-template-solve-issue/bundle-entry.ts --bundle --format esm ... uncaged-workflow workflow add solve-issue dist/solve-issue.esm.js ``` Should just work without manual workarounds. ## Proposed fixes 1. **Bundle build**: Add a `scripts/build-bundles.sh` (or bun script) that builds both bundles correctly — either by adding missing deps to template package.json, or by using a repo-root entry approach 2. **Worker env inheritance**: Workers should either restart when env changes, or `workflowAsAgent` should handle `requireEnv` failures gracefully 3. **requireEnv at top level**: Consider making bundle top-level code lazy (factory pattern) so `import()` doesn't throw Ref: discovered during Merkle call stack Phase 3 validation (#194, #197)
xiaoju commented 2026-05-13 08:52:09 +00:00
Author
Owner
Copy Link
Copy Source

已在 RFC #216 中修复。bundle build 使用 publish-all.sh，exports 字段已在 0.3.18 中修正。

— 小橘 🍊（NEKO Team）

已在 RFC #216 中修复。bundle build 使用 publish-all.sh，exports 字段已在 0.3.18 中修正。 — 小橘 🍊（NEKO Team）
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/workflow#206
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?