Skip to content

Reassemble method called too late when hot reloading #26503

Open

Description

@rrousselGit

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 before reassemble 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.

Activity

  1. rrousselGit commented on Jan 13, 2019

    @rrousselGit
    ContributorAuthor

    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.

  2. added
    frameworkflutter/packages/flutter repository. See also f: labels.
    will need additional triageThis issue or PR needs attention before being routed to secondary triage
    on Jan 14, 2019
  3. Hixie commented on Jan 16, 2019

    @Hixie
    Contributor

    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.

  4. added this to the milestone on Jan 16, 2019
  5. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    c: new featureNothing broken; request for a new capability
    and removed
    will need additional triageThis issue or PR needs attention before being routed to secondary triage
    on Jan 16, 2019
  6. added
    engineflutter/engine related. See also e: labels.
    and removed
    c: new featureNothing broken; request for a new capability
    on Jan 16, 2019
  7. rrousselGit commented on Jan 16, 2019

    @rrousselGit
    ContributorAuthor

    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.

  8. modified the milestones: , on Jan 22, 2019
  9. 33 remaining items

  10. added this to the milestone on Jul 2, 2019
  11. Hixie commented on Jul 2, 2019

    @Hixie
    Contributor

    We talked about how to do this and our theory is that we can fix it like this:

    • Have a service extension that looks like this:
      void foo() {
        debugger(); // from dart:developer, triggers a breakpoint
        reassemble();
      }
    • When we want to hot reload, call this service extension, wait for the isolate to pause.
    • Cause the hot reload, wait for it to finish.
    • Resume the isolate (rather than triggering a reassemble).
    • Wait for the reassemble (the original service extension) to finish.
  12. dnfield commented on Jul 3, 2019

    @dnfield
    Contributor

    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.
  13. dnfield commented on Jul 3, 2019

    @dnfield
    Contributor

    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.

  14. removed this from the milestone on Jun 1, 2020
  15. added
    P3Issues that are less important to the Flutter project
    c: new featureNothing broken; request for a new capability
    and removed on Jul 28, 2020
  16. fzyzcjy commented on Feb 24, 2022

    @fzyzcjy
    Contributor

    Hi, is there any updates?

  17. removed their assignment
    on Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projectc: new featureNothing broken; request for a new capabilityframeworkflutter/packages/flutter repository. See also f: labels.t: hot reloadReloading code during "flutter run"team-frameworkOwned by Framework teamtoolAffects the "flutter" command-line tool. See also t: labels.triaged-frameworkTriaged by Framework team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions