Unhandled TimeoutException error being thrown occassionally

[Srushtika]

Hi there, I've been trying to get a chat app working on Android and iOS emulators. It was working fine before but recently, it started throwing an error occasionally on iOS and almost every time on Android:

E/flutter (12888): [ERROR:flutter/lib/ui/ui_dart_state.cc(177)] Unhandled Exception: TimeoutException after 0:00:02.000000: Acquiring handle timed out.

I chatted with tiholic on Slack. Following his advice, I updated the platform.dart and platform_object.dart files to have the timeout value of 5 instead of 2. I ran it locally with this change and didn't see any errors anymore, neither on Android nor on iOS. It was all working as expected.

The project in question is publicly available if you'd like to try it out and reproduce the error.

┆Issue is synchronized with this Jira Bug by Unito

[tiholic]

@QuintinWillison I think we can increase timeouts to 15 seconds considering worst-case-scenario with end user device capabilities.

Should we do anything other than throwing a TimeoutException? - A custom ably exception with message "Failed to initialize ably library" -or- "Failed to initialize Rest/Realtime instance", respectively

[QuintinWillison]

Just to be clear, as I've not dived deep into the context on this one, is this purely delay within the application process? (i.e. no external asynchronous factors like network calls involved?)

Also, are we only seeing this on one platform or both Android and iOS? Does it only relate to simulators?

It feels to me that 15 seconds is just as arbitrary as 5 seconds which is just as arbitrary as the original 2 seconds... Naively I would have assumed this problem would be measured in a handful of milliseconds at worst.

I would like to establish a value derived from more than a finger in the air, or perhaps consider an alternative approach like a retry strategy (if that's applicable).

What do other libraries do to solve this?

FYI, @paddybyers

[tiholic]

@QuintinWillison Yes, its only related to platform - method calls. no network involved.

iOS might have been faster due to its memory management.

What do other libraries do to solve this?

Other libraries use asynchronous initialization techniques. For us to conform to our spec, we had to adopt a background initialization of respective instances on platform side.

Retry also wouldn't make sense if the device is in-capable of getting a response from platform side in set-timeout. It would always fail leading to a never ending retry loop if we don't break.

I feel best way to go is to increase the timeout to a higher value.

---

FYI, here are the device details with which @Srushtika tried:

Name: Pixel_3a_API_30_x86
CPU/ABI: Google APIs Intel Atom (x86)
Path: /Users/srushtika/.android/avd/Pixel_3a_API_30_x86.avd
Target: google_apis [Google APIs] (API level 30)
Skin: pixel_3a
SD Card: 800 MB
fastboot.chosenSnapshotFile: 
runtime.network.speed: full
hw.accelerometer: yes
hw.device.name: pixel_3a
hw.lcd.width: 1080
hw.initialOrientation: Portrait
image.androidVersion.api: 30
tag.id: google_apis
hw.mainKeys: no
hw.camera.front: emulated
avd.ini.displayname: Pixel_3a_API_30_x86
hw.gpu.mode: host
hw.ramSize: 1536
PlayStore.enabled: false
fastboot.forceColdBoot: no
hw.cpu.ncore: 2
hw.keyboard: yes
hw.sensors.proximity: yes
hw.dPad: no
hw.lcd.height: 2220
vm.heapSize: 256
skin.dynamic: yes
hw.device.manufacturer: Google
hw.gps: yes
hw.audioInput: yes
image.sysdir.1: system-images/android-30/google_apis/x86/
showDeviceFrame: yes
hw.camera.back: emulated
AvdId: Pixel_3a_API_30_x86
hw.lcd.density: 440
hw.arc: false
hw.device.hash2: MD5:0e6953ebf01bdc6b33a2f54746629c50
fastboot.forceChosenSnapshotBoot: no
fastboot.forceFastBoot: yes
hw.trackBall: no
hw.battery: yes
hw.sdCard: yes
tag.display: Google APIs
runtime.network.latency: none
disk.dataPartition.size: 6G
hw.sensors.orientation: yes
avd.ini.encoding: UTF-8
hw.gpu.enabled: yes

[tiholic]

timeout increased to 5 seconds in #75

We can consider increasing it further if this issue repeats.