Description
When a layer node's dependency array contains undefined, the graph compiler fails with an error that identifies nothing:
TypeError: undefined is not an object (evaluating 'a.name')
It comes from resolve in packages/core/src/effect/layer-node.ts:
{ cache, resolve: (node) => replacementMap.get(node.name) ?? node }
node is the undefined entry. In a release build the stack is minified and names no module, and the server reports a generic Unexpected server error.
A dependency ends up undefined when a circular import means the providing module hasn't finished evaluating at the point the deps: [...] array is built. Nothing validates the array, so the failure appears later and far from its cause.
This is what made #48372 hard to pin down: every prompt failed, the surfaced error looked like an auth/provider problem, and several people there suspected their credentials first.
Suggested fix: validate dependencies where the array is built and throw an error naming the node and the offending index, e.g.
Layer node "@opencode/v2/FileSystem" has an undefined dependency at index 2.
That is enough to locate the cycle immediately.
OpenCode version
1.18.30
Steps to reproduce
- Create a circular import between two modules where one module's
deps: [...] reads Other.node from the other.
- Build a bundle whose entry causes the dependency module to evaluate first.
- Run it — the dependency array captures
undefined and compilation dies with the a.name TypeError.
filesystem.ts / filesystem/search.ts is a real instance (fixed separately in #48397); this issue is only about the missing validation and the resulting undiagnosable error.
Description
When a layer node's dependency array contains
undefined, the graph compiler fails with an error that identifies nothing:It comes from
resolveinpackages/core/src/effect/layer-node.ts:nodeis the undefined entry. In a release build the stack is minified and names no module, and the server reports a genericUnexpected server error.A dependency ends up
undefinedwhen a circular import means the providing module hasn't finished evaluating at the point thedeps: [...]array is built. Nothing validates the array, so the failure appears later and far from its cause.This is what made #48372 hard to pin down: every prompt failed, the surfaced error looked like an auth/provider problem, and several people there suspected their credentials first.
Suggested fix: validate dependencies where the array is built and throw an error naming the node and the offending index, e.g.
That is enough to locate the cycle immediately.
OpenCode version
1.18.30
Steps to reproduce
deps: [...]readsOther.nodefrom the other.undefinedand compilation dies with thea.nameTypeError.filesystem.ts/filesystem/search.tsis a real instance (fixed separately in #48397); this issue is only about the missing validation and the resulting undiagnosable error.