Yes, that state is lost today, but does it have to stay that way?
After dispatching the rendered HTML the code could tuck away the state somwhere the second call may retrieve and resurrect instead of rebuilding it from scratch. How the second request is handled proves that it is possible to do do extra things after dispatching the rendered HTM including staying alive for a while longer. I can think of several mechanisms by which to get the state transferred from the process for the first to the process for the second request, including ones that will cross machine boundaries if required.
I’m happy to skin this cat another way if my use-case is that unique. I simply thought some might find it useful if instead of assuming mount/3 will be cheap enough to repeat the platform did what it could to retain the state built to service the first request as initial state for the second request and subsequent stateful web-socket processing.
