Skip to content

fix(signaling): parallelize Pigeon IPC calls in _startService() to reduce FGS delay #1101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SERDUN merged 2 commits into from
Apr 10, 2026
Merged

fix(signaling): parallelize Pigeon IPC calls in _startService() to reduce FGS delay #1101

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5d22e66
fix(signaling): parallelize Pigeon IPC calls in _startService() to re…
SERDUN Apr 10, 2026
c0c6bf1
fix(signaling): parallelize credential writes, keep startService() se…
SERDUN Apr 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 19 additions & 10 deletions packages/webtrit_signaling_service/webtrit_signaling_service_android/lib/src/plugin.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -225,16 +225,25 @@ class WebtritSignalingServiceAndroid extends SignalingServicePlatform {
);
}

await _hostApi.initializeServiceCallback(
dispatcherHandle.toRawHandle(),
// onSync handle is not used directly by Kotlin -- the background isolate
// calls onSignalingServiceSync via PSignalingServiceFlutterApi.setUp.
// Pass 0 as a placeholder.
0,
);

await _hostApi.saveConnectionConfig(config.coreUrl, config.tenantId, config.token);
await _hostApi.saveTrustedCertificates(_encodeTrustedCertificates(config.trustedCertificates));
// Persist all credentials concurrently — they write to independent
// SharedPreferences keys and have no ordering dependency between them.
// Running them in parallel removes two sequential Binder round-trips
// (~200–600 ms under memory pressure) before startForegroundService()
// is called.
await Future.wait([
_hostApi.initializeServiceCallback(
dispatcherHandle.toRawHandle(),
// onSync handle is not used directly by Kotlin -- the background isolate
// calls onSignalingServiceSync via PSignalingServiceFlutterApi.setUp.
// Pass 0 as a placeholder.
0,
),
_hostApi.saveConnectionConfig(config.coreUrl, config.tenantId, config.token),
_hostApi.saveTrustedCertificates(_encodeTrustedCertificates(config.trustedCertificates)),
]);
Comment on lines +233 to +243

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Future.wait([...initialize/save/save/startService...]) can start the service even if one of the prerequisite calls fails: Future.wait will throw on the first error, but the other futures have already been dispatched and may still complete successfully. In the previous sequential flow, a failure in any write prevented calling startService() at all. If you keep parallelism, add logic so startService is only invoked after the prerequisite futures have completed successfully (or stop/rollback the service if a prerequisite fails).

Copilot uses AI. Check for mistakes.

// Start the service only after all credentials are persisted so that
// synchronizeIsolate() reads correct data on the first attempt.
await _hostApi.startService(signalingModeToNative(mode));

// Do NOT clear the hub port here.
Expand Down