Filed by the triage seat as the framework leg of objectstack-ai/cloud#1502 (measured on the released EE 4.1.0 image: OS_CLUSTER_DRIVER=redis ⇒ Cannot find package '@objectstack/service-cluster' imported from /repo/objectstack/packages/cli/dist/commands/serve.js ⇒ migrate exits 1 ⇒ the whole stack cannot start).
Measured mechanism (from the cloud card)
- The image's
/repo/objectstack/packages/cli/node_modules/@objectstack/ holds 48 packages, NOT service-cluster / service-cluster-redis. - Those two are installed only under
/repo/cloud/apps/objectos-ee/node_modules/@objectstack/ (the app's own package.json declares them). serve.js's dynamic import('@objectstack/service-cluster') resolves upward from the CLI's own location and cannot cross the link: boundary; the app side CAN load them (which is why the multi-node guard itself runs). Same defect class as the earlier "CLI dynamic-import auto-discovery cannot resolve cloud packages" (AI Studio) case.
Scope
Fix the resolution so an app-declared optional service package is loadable from the boot path: createRequire anchored at the app config directory (preferred — generalizes to every optional package), or declare the cluster packages as CLI optional deps (narrow). Implementer states the choice and why in the PR; pin with a fixture that loads an app-local-only package through the boot path.
Context note (does not change this card's scope)
The maintainer ruled cloud#1502 direction B (ADR-0010 DB-first; redis leaves the EE templates), so the REDIS route specifically is being de-recommended downstream — but the resolution defect is route-agnostic (any app-declared optional service hits it) and is worth fixing regardless. This card is the mechanism fix, not a redis endorsement.
Refs: objectstack-ai/cloud#1502 (measurement + ruling record) · the AI Studio dynamic-import sibling case.
Filed by the triage seat as the framework leg of objectstack-ai/cloud#1502 (measured on the released EE 4.1.0 image:
OS_CLUSTER_DRIVER=redis⇒Cannot find package '@objectstack/service-cluster' imported from /repo/objectstack/packages/cli/dist/commands/serve.js⇒ migrate exits 1 ⇒ the whole stack cannot start).Measured mechanism (from the cloud card)
/repo/objectstack/packages/cli/node_modules/@objectstack/holds 48 packages, NOTservice-cluster/service-cluster-redis./repo/cloud/apps/objectos-ee/node_modules/@objectstack/(the app's ownpackage.jsondeclares them).serve.js's dynamicimport('@objectstack/service-cluster')resolves upward from the CLI's own location and cannot cross thelink:boundary; the app side CAN load them (which is why the multi-node guard itself runs). Same defect class as the earlier "CLI dynamic-import auto-discovery cannot resolve cloud packages" (AI Studio) case.Scope
Fix the resolution so an app-declared optional service package is loadable from the boot path:
createRequireanchored at the app config directory (preferred — generalizes to every optional package), or declare the cluster packages as CLI optional deps (narrow). Implementer states the choice and why in the PR; pin with a fixture that loads an app-local-only package through the boot path.Context note (does not change this card's scope)
The maintainer ruled cloud#1502 direction B (ADR-0010 DB-first; redis leaves the EE templates), so the REDIS route specifically is being de-recommended downstream — but the resolution defect is route-agnostic (any app-declared optional service hits it) and is worth fixing regardless. This card is the mechanism fix, not a redis endorsement.
Refs: objectstack-ai/cloud#1502 (measurement + ruling record) · the AI Studio dynamic-import sibling case.