Repository navigation
Dart plugin registration doesn't run in background isolates #98591
Description
As we've been adopting in-package platform channels in more 1P plugins, which requires Dart plugin registration, we've hit an edge case related to isolates. While plugins don't generally work out of the box in isolates, there are workarounds which, IIUC, run the native plugin registration code in a separate engine instance so that the native side is there. These systems don't know about the new Dart plugin registration though, so half of the registration code is missing, and we end up with mismatches like #98473.
@gaaclarke @blasten (since you've both looked at the engine/VM integration part of the Dart plugin registration) is there a way we can automatically run the generated Dart registration in each new isolate, rather than just the primary isolate? Alternately, could we adjust the generated registration such that it provides a referenceable function that things like flutter_isolate could call during their isolate setup (similar to the need to call WidgetsFlutterBinding.ensureInitialized())?
Activity
gaaclarke commentedon Feb 16, 2022
I don't think so, and we probably wouldn't want that since it could be wasted in some contexts.
We should be able to do that. I have an outstanding PR that removes the main shadowing and hunts down and executes the registrant on the C++ side. We could expose that function to Dart and have it query the current isolate before executing to see if it already happened.
sarbagyastha commentedon Feb 17, 2022
@stuartmorgan @gaaclarke Is this #98475 issue related too?
But having the issue only when using
--obfuscate.stuartmorgan-g commentedon Feb 17, 2022
I don't see any way that could be related then.
absar commentedon Feb 27, 2022
@stuartmorgan This issue needs to be prioritized, slowly almost every plugin will start having the same issue as you are moving to "in-package method channel", first it was happening with
shared_preferences, nowpath_provider(path_provider_android 2.0.12to be specific)gaaclarke commentedon Mar 1, 2022
flutter-team-archive/engine#31720 has a fix for this issue where a background isolate can call
DartPluginRegistrant.ensureInitialized()to make sure that they've executed. It works in vitro. It has a dependency on a framework change so it will take a while to work through the system. If you are feeling brave you can patch the framework and engine to give it a chance. It would be nice if we could print out a friendlier message too when someone doesn't call this.jack24254029 commentedon Mar 3, 2022
When release
DartPluginRegistrant.ensureInitialized()to stable?stuartmorgan-g commentedon Mar 3, 2022
See https://github.com/flutter/flutter/wiki/Flutter-build-release-channels for an overview of how branching and channel progression works.
pedromassango commentedon Mar 5, 2022
@stuartmorgan can't we just patch into the stable channel? Even though there is a workaround, it is still a critical one
stuartmorgan-g commentedon Mar 5, 2022
Something that required changes in Dart itself, the Flutter engine, and the Flutter tooling cannot be easily cherry-picked, no. Also, this isn't a regression, so definitely would not qualify given the complexity; Dart plugin registration has never worked in isolates. The only thing that changed is the mobile implementations of path_provider and shared_preferences.
The workaround here is very simple, so I'm not sure why you believe that it would be critical to cherry-pick.
kuhnroyal commentedon Mar 9, 2022
Well, I kind of have to agree that this is somewhat critical.
Mainly due to the fact that those
path_providerandshared_preferencesupdates have been released as patch releases and are just transitively being pulled in.Apps that have had working background implementations are breaking left and right. The background code is also not easy to test and these problems are often only showing in production after a store deploy.
Yes, the workaround is simple, the problem is more in the way of knowing/noticing the problem.
stuartmorgan-g commentedon Mar 9, 2022
How would cherry-picking the PR above into stable address this?
kuhnroyal commentedon Mar 9, 2022
You are absolutely right, it wouldn't address that problem by itself.
It could help to have it mentioned in a release announcement and mailing list but other than that your point stands.
Anything else would have to be done on the plugin side (retracting/reverting/major version bump).
gaaclarke commentedon Mar 22, 2022
flutter-team-archive/engine#32162 has caused this to regress. The PR was reverted because of a performance regression with a google app. I think I have a fix for the performance issue. If that doesn't land shortly we will revert the revert.
droplet-js commentedon Mar 28, 2022
any news update?
gaaclarke commentedon Mar 28, 2022
It's just broken on master. We should land the fix before branching for the next release. The engine PR has landed, I'm waiting on a review of the framework PR.
github-actions commentedon Apr 12, 2022
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.