Server queries crash on /product/<id>: stale loader-bundle-env install pairs old @plasmicapp/data-sources with new codegen

[field123]

examples/ep-commerce-app-router does not render. After a clean yarn install from its lockfile, every page returns 500. This blocks using it to validate the 0.2.0 release.

Current state (2026-08-06, master 96b12239d)

Package installed	/products	/product/<real-id>	Error
published 0.0.3 (from lockfile)	500	500	Error executing server queries function TypeError: Cannot read properties of undefined (reading 'state') + TypeError: Cannot read properties of null (reading 'useContext')
master build over clean tree	500	500	Cannot find module '.../node_modules/next/server' imported from .../dist/server.mjs

Two separate problems

1. The lockfile pins a package three months behind the example's source. package.json asks for *, the lockfile resolves 0.0.3, and the example's own code has since moved on with master (createBetterEpAuth, hostAllowlist, and so on). The useContext null is consistent with that mismatch rather than with a React duplicate — only one React 19.2.5 is installed.

2. The ESM /server entry may not resolve. See the handoff / separate investigation. dist/server.mjs imports the bare specifier next/server, and Next 15.5.15 ships no exports field, so only legacy CJS lookup can resolve it. Unconfirmed whether this affects real consumers or only this local setup.

Also worth knowing

• Before the clean install, the tree carried three copies of @plasmicapp/host (2.0.1, 1.0.233, 1.0.240) and Plasmic warned Encountered likely duplicate host version. That produced a duplicated function registry (16 entries for 8 functions) and an execParams crash. All of it disappeared after the clean install — it was local rot, partly self-inflicted by hand-copying builds into node_modules. Recorded here only so the symptoms are recognisable if they recur.
• EP_CLIENT_SECRET is unset in the local .env.local, so checkout's admin paths (Stripe registration, server-computed money) stay disabled regardless of the above.

Suggested first step

Decide what the example should build against — the published package or the workspace source — and make the lockfile say so. Much of the confusion above comes from it being neither.

[field123]

Root cause found for the 500s — and it is not the EP package

The Cannot find module '.../next/server' failure is caused by @elasticpath/plasmic-mcp-registry, not by plasmic-ep-commerce-elastic-path.

The published registry 0.2.1 still externalises Plasmic packages via serverExternalPackages / webpack externals. Externalising means Node — not webpack — loads dist/server.mjs, which imports the bare specifier next/server. Next 15.5.15 ships no exports field, so Node's ESM loader cannot resolve that specifier and the module fails to load.

Master's registry (same version number, 0.2.1, unpublished content) empties those patterns deliberately, letting webpack bundle everything. That removes the failure.

A/B matrix

EP package	registry	pages	next/server ESM error
published 0.0.3 (no server.mjs)	published	500	no
master build	published	500	yes (8)
published 0.1.0	published	500	yes (8)
published 0.1.0	master	200	0

Published 0.1.0 and master's build emit an identical from "next/server", and their package.json manifests (version, exports, deps) are identical — so the EP package is not the variable. The registry is.

Implication: the fix already exists on master and is simply unpublished. Publishing the registry should resolve the 500s for consumers.

Still outstanding, and independent

With the 500s gone, the page renders but stays on Loading..., and the server logs persist:

Error executing server queries function TypeError: Cannot read properties of undefined (reading 'state')
⨯ [TypeError: Cannot read properties of undefined (reading 'execParams')]

This reproduces with published 0.1.0 on a clean tree, so it predates and is unrelated to PR #393. Likely candidates: the Studio project's saved server queries being out of sync with the current registration shape (there is an unaccepted "Refresh code component props" prompt on the project). That is the remaining thing to investigate.

[field123]

Correction to my previous comment — "200" does not mean working

I reported published 0.1.0 + master registry as 200, and implied the page renders. That was wrong, and I only checked the HTTP status plus an innerText read taken too early.

Verified in a real browser (Playwright), waiting 15s after navigation:

document.body.innerText
→ "Application error: a client-side exception has occurred while loading localhost"
   (127 chars, 52 DOM nodes, none of them the product)

I had earlier seen Loading... and reported the page "sits on Loading". That was a transient state sampled at 0s and 5s; by 15s it has crashed. Both readings were wrong.

What the registry swap actually changed

	published registry	master registry
HTTP	500	200
Module load	fails — Cannot find module '.../next/server'	succeeds
Page in browser	error	still crashes — Application error

So the registry fix removes the module-loading failure and reveals the underlying one. It does not make the app work. The remaining errors, present in both configurations:

Server: Error executing server queries function TypeError: Cannot read properties of undefined (reading 'state')
Client: TypeError: Cannot read properties of undefined (reading 'execParams')
          at @plasmicapp/loader-core

The client error is what kills the page — it throws during React render, so the whole tree unmounts into the error boundary.

Net: the example is still broken end to end. Publishing the registry is necessary but not sufficient. The server-query failure remains the blocking issue.

[field123]

Root cause of the server-query crash — found

The Plasmic bundle's component metadata references a server-queries exec module that the bundle does not contain.

Measured from inside the RSC page itself (temporary probe in app/[[...catchall]]/page.tsx, since a Route Handler could resolve a different export condition and give a misleading answer):

server: 0, browser: 32
needs:  "__loader_rsc_ProductList_z2CZmql63OZv.js"
found:  false
rscMods: []          ← no __loader_rsc_* modules exist in the bundle at all

So:

1. entryCompMetas[0].serverQueriesExecFuncFileName names an exec module.
2. bundle.modules.server is empty — the bundle is browser-only (32 browser modules, 0 server).
3. The loader dereferences the named module, gets undefined, and reads .execParams / .state off it.
4. That throw happens during React render, so the tree unmounts into the error boundary — the Application error the user sees.

Ruled out

• Not mode. With preview: false the bundle is still server: 0 (24 browser modules).
• Not a Route-Handler measurement artefact. The RSC page reports the same.
• Not PR Security: production-guards batch — consolidates the six mechanical #279 fixes #393, and not the EP package — reproduces on published 0.1.0 with a clean dependency tree.
• Not the nextjsAppDir option being unset. plasmic-init.ts passes platformOptions: { nextjs: { appDir: true } }, and loader-fetcher maps that to a nextjsAppDir=true query param.

Where that leaves it

The failure is that Plasmic's loader API returns a bundle advertising a server-queries exec module while shipping no server modules. Next step is to determine why — candidates: the project's server queries were never saved/published in a form that generates the exec module, or nextjsAppDir=true is being sent but not honoured for this project/revision.

extractEpProviderConfig is unaffected: it reads server modules first, then falls back to browser, and the EP config resolves fine from the 32 browser modules.

[field123]

The bundle comes from our own wab, not plasmic.app

plasmic-init.ts sets host: "http://localhost:3003". In @plasmicapp/loader-fetcher:

this.apiHost = opts.apiHost ?? opts.host ?? "https://codegen-origin.plasmic.app"

So host is the API host — the loader fetches bundles from localhost:3003, which is this repo's wab (rsbuild-node, confirmed as the listening process). The empty modules.server is therefore produced by our fork's codegen, not by Plasmic's hosted service.

Is it upstream drift? Not on this code path

• Fork is 393 commits behind upstream/master (and 329 ahead).
• No unmerged upstream commit touches serverQueriesExecFunc. The unmerged commits on module-bundler.ts / routes/loader.ts are unrelated: CSS url() externalisation, distributed tracing, analytics sampling, cache metrics, response headers.
• The generation code is present in our fork — module-bundler.ts:175 passes c.rscMetadata?.serverQueriesExecFunc?.fileName to esbuild as an entry point, and :695 sets the metadata name the loader later looks for.

So the name is emitted and the entry point is registered, yet the bundle ships . The gap is between those two, in our own code.

Suggested next step

The esbuild call at module-bundler.ts:~160-200 runs per target. Work out why the node/server pass yields no modules for this project — whether it is skipped, produces nothing, or is dropped before serialisation. That is a wab-side investigation and is independent of the EP commerce package entirely.

Worth also confirming against a non-local API host (drop host from plasmic-init.ts) to see whether the same project produces server modules elsewhere — that isolates our wab from the loader and the project data.

[field123]

Retracting the last paragraph of my previous comment. I suggested dropping host from plasmic-init.ts to compare against Plasmic's hosted service. That is wrong and should not be done — Elastic Path runs a standalone fork and does not route to upstream's hosted infrastructure. Ignore that suggestion.

The isolation experiments should stay entirely within our own stack:

• Does any project served by our wab produce a non-empty modules.server? If none do, the server/node esbuild pass is broken generally rather than for this project.
• Instrument the esbuild pass at module-bundler.ts:~160-200 directly — it runs per target; establish whether the node pass is skipped, produces nothing, or has its output dropped before serialisation.
• Check whether wab's own codegen tests cover server-query exec-module emission, and whether they pass. If they do, the generation logic is sound and the fault is in options/plumbing rather than codegen.

[field123]

Root-caused and fixed: stale loader-bundle-env install, not wab codegen

The Cannot read properties of undefined (reading 'state') crash is resolved. The earlier diagnosis in this issue and in the handoff pointed at wab generating a bundle with an empty modules.server. That was wrong — wab's bundle was correct the whole time.

What it actually was

esbuild resolves loader bundle dependencies through platform/loader-bundle-env/node_modules (platform/wab/src/wab/server/loader/module-writer.ts:16-20). That tree was installed 9 Apr against a yarn.lock last updated 27 Apr and never reinstalled — 49 of 59 Plasmic packages were a generation behind.

The consequence was two incompatible versions of @plasmicapp/data-sources welded into one bundle:

	API
Generated exec module (__loader_rsc_*.js)	executePlasmicQueries(serverQueryTree, {$props, $ctx}), destructures {cache}
Bundled runtime (installed 1.0.0)	executePlasmicQueries($queries, queries)

The old runtime does Object.entries() over argument 1, expecting Record<name, StatefulQueryResult>. Handed a node tree, the first entry is ["type", "component"], so $query becomes the string "component" and $query.current.state throws.

The lockfile pins 1.0.2, which has the new API. Only the installed tree was stale.

Fix

cd platform/loader-bundle-env && yarn install --frozen-lockfile

0 of 59 stale afterwards; yarn.lock unchanged; no code change required.

Scope: local only

platform/wab/Dockerfile:15 installs --frozen-lockfile from scratch, and the CI cache key in .github/actions/setup-env/action.yml:36 is hashFiles('**/yarn.lock'), which covers this lockfile. Deployed wab and CI were never affected. This was not a 0.2.0 publish blocker.

Corrections to the record above

• modules.server was never empty. Fetched directly from the local wab: server: 127, browser: 127, including all three __loader_rsc_* modules. The server: 0 figure measured from the RSC page was real but irrelevant — getBundleSubset (packages/loader-core/src/bundles.ts:47-48) empties the non-target side by design, and the registry loads from the loader's internal bundle, not from prefetchedData.bundle.
• browserOnly was not involved.
• The execParams crash was a downstream symptom, not the fault. The real error was server-side, swallowed by the try/catch in unstable__getServerQueriesData (packages/loader-react/src/loader-shared.ts:947-953), which returns {} and leaves the client to fail on the empty result.
• Not every page 500s. /products rendered correctly throughout (34 results). Only /product/<id> — the page with a server query — crashed, and it returned HTTP 200 while dying in the browser.

Verification

	Before	After
/product/<id>	Application error: a client-side exception has occurred	Renders "Testing Product Catalog", $12.32, description
Product name in SSR HTML	absent	present
Error executing server queries in log	yes	0
Browser console errors on PDP	2	0
/products	34 results	34 results (unchanged)

Isolated repro used to confirm the cause: the exec module and its chunks were lifted out of the bundle and executed in a plain Node harness with a stub query function, reproducing the throw off Next entirely — proving it was loader runtime code rather than EP's getProduct.

/products never server-renders its products, before or after; it uses a client-side search component. The setState-in-render warning from PlasmicProductList is also pre-existing and unrelated to this issue.

Still open

1. Problem 2 in the description (ESM /server entry — dist/server.mjs importing bare next/server) was not investigated here and remains unconfirmed.
2. The lockfile question in "Suggested first step" still stands: the example builds against neither the published package nor the workspace source cleanly.
3. No guard against this class of failure. wab's codegen and the bundled runtime are versioned independently, and a mismatch surfaces as an unrecognisable TypeError deep inside minified bundle code with no indication of a version problem. Worth a build-time assertion; filing separately.