Repository navigation
fix(android): admit foreground workers before promoting to foreground (#95) - #96
Merged
Merged
Conversation
…#95) ForegroundNativeWorker called setForeground() before TaskConcurrency, so with maxConcurrentTasks: 1 every waiting worker still promoted itself and booted its Flutter engine. Order is now: wait for permit -> promote -> run -> release, sharing one permit. Background fallback on rejected promotion is kept, CancellationException is rethrown, and the cancel path logs phase, work id, isStopped, stopReason and runAttemptCount. Tests: ForegroundAdmissionTest (6, JVM), two issue_95 device smoke tests, FGS demo button. On an API 34 emulator promotions went from 6 within ~130 ms to one per ~0.6 s. The reported cancellation itself is not reproduced.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #95 (doesn't close it, see below).
With maxConcurrentTasks: 1, ForegroundNativeWorker called setForeground() before the TaskConcurrency permit, so every waiting worker still promoted itself and booted its own Flutter engine. Callbacks were serialized, promotion wasn't. That ordering came in with the limiter in 1.9.0 (#84).
Order is now: wait for permit -> promote -> run -> release. Promotion and execution share one permit (no nested acquire), waiters don't promote, cancel frees the slot. Background fallback when promotion is rejected is unchanged, CancellationException is rethrown, and the cancel path logs phase / work id / isStopped / stopReason / runAttemptCount. Periodic scheduling is untouched.
Tests
Not confirmed
Couldn't reproduce the reported cancellation, not even on 1.9.0 with 12 workers. Cause is still unknown, so I'd keep #95 open until we get a stop reason from the reporter. Didn't verify multiple periodic cycles either.