Seeking Insights on SolidStart Server Function Issue
Hi everyone! I've encountered a strange behavior in a SolidStart project involving server functions and page refreshes. I've detailed the issue, steps to reproduce, and provided a demo repo and code examples here: GitHub Issue.
If anyone has insights or suggestions, I'd greatly appreciate your input!
3 Replies
Going through these steps:
Go to Authors and select an author (e.g., /author/1). Enter a new value into the input box under "Update value using Server Function." Click Save. The new value should be displayed.I saw this on the server side: The server utilizes multiple workers for various capabilities. So what seems to have happened here is that is that "Update value using Server Function" created an entirely new store in a different worker and updated that. Edit: Meanwhile refreshes are SSRed from the other store. FYI: https://github.com/peerreynders/server_-routes-lobotomy
GitHub
GitHub - peerreynders/server_-routes-lobotomy: Demonstration of bri...
Demonstration of bridging communication between the isolated server and routes processing - peerreynders/server-routes-lobotomy
The initial
/ request creates the first store. The second store is created when you navigate to /authors.
1st store (route worker): POST \api\authors\ {:id}
2nd store (serverFn worker): getAuthors, getAuthor, updateAuthorAction
This is consistent with what I have observed so far. Route logic in one worker, "use server" in another.
What I cannot explain is why/how getAuthor accesses the first store on refresh.
My hypothesis that the refresh is SSRed entirely in the route worker, so even the "use server" sections are running just in the route worker accessing the route worker's store.Thank you so much for your help in debugging the issue. Your explanation about how the server utilizes multiple workers for various capabilities really clarified the problem. It seems that the "Update value using Server Function" created an entirely new store in a different worker and updated that.
Reflecting on the issue I opened, it is the textbook definition of data inconsistency across multiple workers. The docs should emphasize this behavior. Reading directly from a file and writing to it solved the issue. Turns out it’s not only that—the failing of the revalidation call after API updates was also tied to this issue. With the new logic, this now works as expected. Probably, revalidation was working as expected but was using the stale data.
I wonder what the source of this behavior is—Nitro maybe? It would be great if they discussed the underlying architecture more or provided guidance to help people avoid running into these kinds of issues, saving time and frustration.