-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: await requests to before server restart #13262
Conversation
Run & review this pull request in StackBlitz Codeflow. |
Fixed now: |
/ecosystem-ci run |
📝 Ran ecosystem CI: Open
|
We could revert #13231 after this PR, as old plugins should always see the correct Note: Nuxt is expected to fail, it is also failing in main now. |
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
@@ -46,6 +47,8 @@ export function transformRequest( | |||
server: ViteDevServer, | |||
options: TransformOptions = {}, | |||
): Promise<TransformResult | null> { | |||
if (server._restartPromise) throwClosedServerError() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it's worth having a method like server.throwIfClosed()
to encapsulate this logic and potentially avoid needing to access a private variable. not sure if you'd want to expose this externally, but if so then middlewares could call it if necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an interesting idea. I think we better explore it in a separate PR, and once we have a use case from a middleware to justify exposing the function. transformRequest
is internal to vite so I think it is fine reading _restartPromise
here for now, and we may find a better way to stop the execution later. Throwing here feels a bit hacky to me to expose it.
I left a few small comments, but looks good to me! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some tiny nits. Looking forward to trying this in the minor!
Maybe we should also rebase the branch before merging just in case we miss a change from |
Description
When a server is restarted,
server.moduleGraph
will end up being a new clean graph. Butserver
a single object, that we keep across restarts. Outdated plugins and middlewares may be processing requests and if they useserver.moduleGraph
they could crash or add outdated modules or relationships to the new graph.This PR awaits processing to be done before doing
Object.assign(server, newServer)
We were already awaiting the
pluginContainer
to close, but this was only callingbuildEnd
andcloseBundle
. It nows await for all hooks to finish.We also await from
server._pendingRequests
.See #13231 (comment)
We also discussed with @antfu that a Proxy could be used to give the plugins a view that keeps
server.moduleGraph
pointing to the old graph. Theserver
proxy that plugins will get inconfigureServer
will be this proxy. I think this could be worth exploring, but if we properly await for the plugins to finish processing, we shouldn't need to do it.What we may be missing now is to await for external middlewares. We can check this in a future PR.
What is the purpose of this pull request?