[DWDS] Fixes hot reload/restart crashes after closing browser tab on web-server device #2699
Conversation
| _logger.info('No clients available for hot restart'); | ||
| return { | ||
| 'result': { | ||
| 'type': 'Success', |
There was a problem hiding this comment.
This doesn't feel right as this isn't a Success.
Realistically, we should be doing something like throwing an RPCError with an error code that package:vm_service forwards without modification. Right now, package:vm_service catches all exceptions and wraps them in RPCErrors with a kServerError code, but maybe we should update it to rethrow RPCError instances.
Another option would be to update the hotRestart extension to return ReloadReport as well so we can be consistent between hotReload and hotRestart.
There was a problem hiding this comment.
Good catch! This shouldn’t be treated as a success. I think returning a ReloadReport would be the better approach to keep things consistent and also add the field noClientsAvailable. For now, I’ve removed the type field since it’s not being used for this operation.
In another PR, we can refactor this to return a ReloadReport instead, that would also involve updating the Chrome path and Flutter tools as well, as they currently expect the existing format.
There was a problem hiding this comment.
How does that sound? @bkonyi
There was a problem hiding this comment.
I actually don't think we can remove the type property in the result without consequence. package:vm_service checks for this and, if it can't find the type, returns a Response by default. While I don't think anyone is checking for the Success object explicitly since there's no useful information attached to it, this could break things.
I think it's just worth updating the return type to be ReloadReport now and then updating Flutter to return the same when we roll this change.
There was a problem hiding this comment.
Hmm, I feel like this resurrects the original issue we had where we can't distinguish what the kServerError corresponds to, whereas if we had hot restart return a ReloadReport, we have that metadata in the report.
(also I'll be OOO tomorrow, so if you decide this is the right approach anyways, feel free to land it)
There was a problem hiding this comment.
Hey Srujan, Ben sand I discussed this and decided that this approach to throw an RPCError would work better since changing hot restart to return a ReloadReport would also require modifying the Chrome path, which could introduce some breakage.
In Flutter tools, I check for the calling method and kServerError to distinguish that this is the specific scenario. We could technically add a new RPCErrorKind for this, but I’m not sure it’s really necessary.
Thoughts? @bkonyi
There was a problem hiding this comment.
If we'd like to avoid using the generic kServerError, I think we can go ahead and use kIsolateCannotReload to indicate that the reload has failed.
yes that's correct I have added a test in flutter tools for this scenario |
3 participants
This PR introduces graceful handling for scenarios where no browser clients are connected to DWDS during hot reload and hot restart operations. Previously, DWDS threw generic
StateErrorexceptions that required Flutter Tools to parse error messages using brittle string matching. Now, a customNoClientsAvailableExceptionis thrown and caught, with structured error responses that include anoClientsAvailableboolean field in the JSON output. This enables type-safe error handling and eliminates the need for error string parsing. The changes affect thereloadSourcesandhotRestartmethods inWebSocketProxyService, which now return success responses with metadata when no clients are available, treating this as a recoverable scenario rather than a fatal error.Related to flutter/flutter#174791
Changes in Flutter tools (Child PR): flutter/flutter#177026