Summary
The Settings page (and any other route that renders a MUI Select) crashes
on initial render in 1.20.0 with:
MUI: MenuListContext is missing. MenuItems must be placed within Menu or MenuList.
The page renders blank, and the browser's Network tab shows no API requests
firing, because the React tree throws during render before any data fetching
runs. Rolling back the client to 1.19.0 restores it.
Environment
- Image:
yooooomi/your_spotify_client:1.20.0
- Server:
yooooomi/your_spotify_server:1.20.0
- MongoDB:
mongo:7.0.34
- Caddy in front for HTTPS (Spotify OAuth redirect requirement)
- Browser: any (Chromium and Firefox both reproduce)
Repro
- Pull
yooooomi/your_spotify_client:1.20.0 and yooooomi/your_spotify_server:1.20.0.
- Bring the stack up, complete the Spotify OAuth flow, land on the dashboard.
- Click the gear icon (Settings).
- Page renders blank. F12 → Console shows the error below. Network tab shows no API calls.
Console error
349.a48f55e24b.js:158 Uncaught Error: MUI: MenuListContext is missing.
MenuItems must be placed within Menu or MenuList.
at o (349.a48f55e24b.js:158:8694)
at 349.a48f55e24b.js:158:7659
at l6 (lib-react.46d02465ac.js:2:51013)
at ow (lib-react.46d02465ac.js:2:69147)
at oW (lib-react.46d02465ac.js:2:85655)
at uk (lib-react.46d02465ac.js:2:116058)
at ub (lib-react.46d02465ac.js:2:115911)
at uu (lib-react.46d02465ac.js:2:112067)
at uX (lib-react.46d02465ac.js:2:134531)
Likely cause
The Settings JSX is correct — every MenuItem is inside a Select /
MenuList. The error fires because MUI's useMenuListContext() hook is
returning null at runtime. The usual cause for this in MUI v5+ is two
copies of @mui/material in the bundle: the Select from copy A installs
its context, but the MenuItem from copy B reads from a different context
instance, so the lookup fails.
PR #569 (merged Nov 2025, shipped in 1.20.0) swapped the client's build tool
from webpack to rspack. rspack's module hoisting differs subtly from webpack;
the most common manifestation in MUI-heavy React projects is duplicate
package output when chunk-splitting boundaries don't dedupe nested
node_modules paths the same way.
Workaround
Pin the client and server to 1.19.0 (last webpack-built release):
your_spotify_server: yooooomi/your_spotify_server:1.19.0
your_spotify_client: yooooomi/your_spotify_client:1.19.0
The 1.20.0 → 1.19.0 mongo schema rollback is non-destructive — Mongoose
ignores the migration entries the older server doesn't know about, no data
loss, no re-auth needed.
Suggested fix direction
Either:
- Configure rspack to dedupe
@mui/material via splitChunks.cacheGroups
(treat it as a singleton chunk), or
- Hoist
@mui/material to a single top-level dependency in the workspace
so rspack only sees one resolved path.
A quick check on the published 1.20.0 client Docker image would confirm:
inspect the bundled JS for two occurrences of MuiSelectContext /
MenuListContext provider initialization. If there are two, that's the
duplication.
What I checked first
- All
MenuItem usages in apps/client/src/scenes/Settings/* are correctly
wrapped in Select / FormControl. Source-level JSX is not the bug.
- Search of the repo issues for
MenuListContext, MenuItem outside Menu,
and rspack returned no existing reports as of 2026-05-28.
- 1.19.0 (last webpack build) does not exhibit the issue with the same data
and the same OAuth setup.
Happy to test a candidate fix branch / image tag if it would help.
Summary
The Settings page (and any other route that renders a MUI
Select) crasheson initial render in
1.20.0with:The page renders blank, and the browser's Network tab shows no API requests
firing, because the React tree throws during render before any data fetching
runs. Rolling back the client to
1.19.0restores it.Environment
yooooomi/your_spotify_client:1.20.0yooooomi/your_spotify_server:1.20.0mongo:7.0.34Repro
yooooomi/your_spotify_client:1.20.0andyooooomi/your_spotify_server:1.20.0.Console error
Likely cause
The Settings JSX is correct — every
MenuItemis inside aSelect/MenuList. The error fires because MUI'suseMenuListContext()hook isreturning
nullat runtime. The usual cause for this in MUI v5+ is twocopies of
@mui/materialin the bundle: theSelectfrom copy A installsits context, but the
MenuItemfrom copy B reads from a different contextinstance, so the lookup fails.
PR #569 (merged Nov 2025, shipped in 1.20.0) swapped the client's build tool
from webpack to rspack. rspack's module hoisting differs subtly from webpack;
the most common manifestation in MUI-heavy React projects is duplicate
package output when chunk-splitting boundaries don't dedupe nested
node_modulespaths the same way.Workaround
Pin the client and server to
1.19.0(last webpack-built release):The 1.20.0 → 1.19.0 mongo schema rollback is non-destructive — Mongoose
ignores the migration entries the older server doesn't know about, no data
loss, no re-auth needed.
Suggested fix direction
Either:
@mui/materialviasplitChunks.cacheGroups(treat it as a singleton chunk), or
@mui/materialto a single top-level dependency in the workspaceso rspack only sees one resolved path.
A quick check on the published
1.20.0clientDocker image would confirm:inspect the bundled JS for two occurrences of
MuiSelectContext/MenuListContextprovider initialization. If there are two, that's theduplication.
What I checked first
MenuItemusages inapps/client/src/scenes/Settings/*are correctlywrapped in
Select/FormControl. Source-level JSX is not the bug.MenuListContext,MenuItem outside Menu,and
rspackreturned no existing reports as of 2026-05-28.and the same OAuth setup.
Happy to test a candidate fix branch / image tag if it would help.