Uncaught (in promise) TypeError: Cannot use 'in' operator to search for 'data' in undefined
Describe the bug
When server-created createResource got read after getting resolved, Uncaught (in promise) TypeError: Cannot use 'in' operator to search for 'data' in undefined error happens on the server.
Your Example Website or App
https://github.com/XiNiHa/solid-relay/tree/feat/ssr-defer
Steps to Reproduce the Bug or Issue
- Clone the repo with
feat/ssr-deferbranch -
pnpm i,pnpm build,cd examples/ssr,pnpm dev - Open the index route (with Firefox, as mentioned below)
- Refresh the page until the page is broken. (no content after
Additional data...fallback goes away) Found that this bug only happens occasionally. - Check the browser console to see the error streamed in.
Expected behavior
I expected the resource to resolve without triggering any errors.
Screenshots or Videos
Expected behavior:
https://github.com/solidjs/solid/assets/8155259/7d14604c-b65e-4cb3-8690-c3de5e67f4e8
Bug happening:
https://github.com/solidjs/solid/assets/8155259/5e40f58a-acaf-41ae-a4ea-472547bffb5a
Platform
- OS: macOS (didn't verify with other OSes yet)
- Browser: Firefox (verified that Chrome works without any problem, was not able to exactly reproduce in Safari due to streaming SSR not working, but the error didn't happen at least)
- Version: 115.0.2 (latest stable at the time)
Additional context
The exact position where the error is happening is here (verified by monkey-patching the code. adding sharedConfig.context!.resources[id] && check before the in prevented the error from happening, but then made another error happen at here by accessing .data in undefined)
Monkey-patching to replace all sharedConfig.context!.resources[id] access in read() to resource resolved the issue.
The bug happens much less frequently in a Private Window.
This is an odd issue. I never reproduced it ever in Chrome, and the only thing that resembled it Firefox it wasn't the same errors you were getting. It was name or metadata of undefined which I couldn't find the code for. And even after applying both fixes I could still reproduce it.
Even stranger is that if we assume you made your first fix, there is no way during synchronous code execution the second issue like you pointed at could error. If your condition prevented it from being resolved how could that branch of the ternary ever execute?
For the browser to make a difference on server code seems highly unlikely unless maybe this something related to the development environment. Did you ever try running this in prod mode (I had no luck it was trying to open up an invalid port)?
Right now I can confirm there is something up, but I can't reproduce the issue you were having or its relation to Solid code.