You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reassemble method called too late when hot reloading #26503
Consider a widget that rebuilds very often (typically because of an animation).
Then consider editing the sources of that widgets through hot-reload.
It seems that when doing so, there's a chance for build method to be called beforereassemble was, but with the updated content.
This is a big issue for the following open source library: https://github.com/rrousselGit/flutter_hooks
As it needs to override the reassemble behavior to handle potential changes within build method.
But if build method is called before reassemble, then the library won't be ready for it and the app will enter into an invalid state.
We probably don't pause the VM while we're updating it, so there's a race between us finishing the update of the code, and us sending the message to do the reassemble. But fundamentally we can't have the VM be paused while we send it the message, because it's code running inside the VM that has to respond to the message...
We could send a "stop handling frame messages" message before we do the update, then do the update and schedule the reassemble, then re-enable handling of frame messages. That would need changes to the tool and the framework.
Is there anything I can do to fasten the fix, or any potential workaround?
This is the source of a fairly common bug when using the package listed above. That is because, with hooks we tend to not use builders such as AnimatedBuilder, and do the listening directly on the widget needing it.
That's fine but it means that with this issue, working on an animated widget while its animation is playing has about 50% chance to make the library throw.
I was pretty sure I had tried that, but really I had just tried something very close to it.
I think I have another idea about how to make this work now. The thing blocking me before was that I wouldn't make progress because:
You can't await the call that ends up setting a debugger - it won't return until the isolate is resumed, and the code that would resume it is going to come after the future completes.
We have logic to look for paused isolates and skip calling reassemble on them, the idea being that someone else paused them and we shouldn't be resuming them. We'd have to shuffle that around to look for paused isolates earlier instead.
I'll need to come up with some way to test this, and to test the change I'm making to vmservice.dart, but https://github.com/flutter/flutter/pull/35514/files is yet another attempt that seems like it might work.
I got mixed up earlier on this one because I mistakenly thought setting the breakpoint was failing the hot reload - it wasn't, it just was that I was either awaiting something I couldn't, or that the isolate wasn't getting marked as resumed even when it was, or some combination of those factors.
Activity
rrousselGit commentedon Jan 13, 2019
That issue is critical for the sanity of https://github.com/rrousselGit/flutter_hooks
As such, I can work on it if needed. But I need some guidance, as I don't know where to start.
Hixie commentedon Jan 16, 2019
We probably don't pause the VM while we're updating it, so there's a race between us finishing the update of the code, and us sending the message to do the reassemble. But fundamentally we can't have the VM be paused while we send it the message, because it's code running inside the VM that has to respond to the message...
We could send a "stop handling frame messages" message before we do the update, then do the update and schedule the reassemble, then re-enable handling of frame messages. That would need changes to the tool and the framework.
rrousselGit commentedon Jan 16, 2019
I see, thanks for the explanations.
Is there anything I can do to fasten the fix, or any potential workaround?
This is the source of a fairly common bug when using the package listed above. That is because, with hooks we tend to not use builders such as
AnimatedBuilder, and do the listening directly on the widget needing it.That's fine but it means that with this issue, working on an animated widget while its animation is playing has about 50% chance to make the library throw.
33 remaining items
Hixie commentedon Jul 2, 2019
We talked about how to do this and our theory is that we can fix it like this:
dnfield commentedon Jul 3, 2019
I was pretty sure I had tried that, but really I had just tried something very close to it.
I think I have another idea about how to make this work now. The thing blocking me before was that I wouldn't make progress because:
dnfield commentedon Jul 3, 2019
I'll need to come up with some way to test this, and to test the change I'm making to vmservice.dart, but https://github.com/flutter/flutter/pull/35514/files is yet another attempt that seems like it might work.
I got mixed up earlier on this one because I mistakenly thought setting the breakpoint was failing the hot reload - it wasn't, it just was that I was either awaiting something I couldn't, or that the isolate wasn't getting marked as resumed even when it was, or some combination of those factors.
fzyzcjy commentedon Feb 24, 2022
Hi, is there any updates?