FAILURE_DURING_TRANSFER issue again (now using Comm sample )

ArtaudAntonin / Jiri Richter over 7 years ago

Environment:
- Ubuntu 16.04
- Vivoactive V4.40, CIQ1.4.2
- Android 6.0.1
- Android Studio 2.3.2
- CIQ SDK 2.2.5
- CIQ Android Mobile SDK v1.4

A detailed description of the issue:

Using modified Comm samples from CIQ SDK 2.2.5 and CIQ Android Mobile SDK v1.4, I can get to the point where any attempt at communication phone => watch results in FAILURE_DURING_TRANSFER, while in the other direction messages go through normally.

Steps to reproduce the issue:

1. Install both apps from the following repository: https://github.com/Artaud/CIQ-Comm-failure-sample and run them.
2. On Android, tap on your connected device to select it. The app will now start receiving messages from watch.
3. Try to send any message to the watch and check the Android log. You'll get FAILURE_DURING_TRANSFER very early.
4. Turn off the app on watch and try to send any message from the phone now. Normally, you should get SUCCESS even if the app is not running, but now you get FAILURE_DURING_TRANSFER forever.

Additional information:

The bug makes any serious two-way communication impossible.

Code sample to reproduce the issue:

https://github.com/Artaud/CIQ-Comm-failure-sample

Top Replies

All Replies

TheodorStorm over 5 years ago

Same problem here. Everything works fine if only the watch is sending messages to the companion app, but if the app is also sending messages to the watch this issue appears within minutes. It also causes either the watch app to crash or the watch to reboot (I've seen both happening, no information in the debug log though).

Garmin Fenix 5X, ConnectIQ SDK 3.0.6, Samsung A6, Android 8.0.0.

I'm only sending one message at a time and allows a one second delay between each message. If you need help beta testing the fix you are working on, let me know. I'm sure all subscribers to this thread are willing to help in any way possible.

ArtaudAntonin / Jiri Richter over 5 years ago

I'm sorry but can I ask for any - any - information about this? I've just checked the date I started this thread and it's been almost two years this bug exists. It has been always in the Garmin SDK. For the whole two years, my app will one day work and the other it won't, and when I explain my users why, they usually get pretty mad at Garmin. I'm really glad that we and Garmin have intelligent users who don't throw blame blindly, but it would be so much better if there was no need for blame.

Is this ever going to be fixed? I spent thousands of dollars in man-hours on trying to workaround this bug, but it always comes down to randomly locking up the Comm. Should I contact someone else? Should I provide anything more than the sample to reproduce? I'm really desperate at this point.

Stephen.ConnectIQ
Coleman.ConnectIQ

Stephen.ConnectIQ over 5 years ago

ArtaudAntonin I did bring this up with our engineering team, and It has been moved to be looked at by the correct team. I do not have any info for when a fix will be implemented, but it is in the process. Thanks for your patience on this issue.

ArtaudAntonin / Jiri Richter over 5 years ago

Thank you Stephen.ConnectIQ, I understand you did the most you could. Hope it's not too much of a complicated bug to fix...

ArtaudAntonin / Jiri Richter over 5 years ago

Hi, any news?

Jan Čapek over 5 years ago

Please help me understand this issue.

So, during communication via Toybox.Communications from Android to Garmin everyone (and with any Garmin devices?) are getting random FAILURE_DURING_TRANSFER. Communication in other direction is unaffected.
Those errors after while cause to overflow some collector in Garmin Connect Mobile app and after that every message without exception will fail with the same error, so there is no way how to push data to Garmin from Android. The only way how to make connectivity to work again is to manually restart Garmin Connect Mobile Android app in phone.
Garmin is not able to fix this issue for two years already, while keep reporting that they are looking into it. So, fixing this issue soon is very unlikely and the issue is nowhere documented and simulator is unaffected by this, so devs will find out only after testing of their apps with real devices.

Is this correct - did I miss something?

In my case messages fails every 5th message in average in beginning until "100% fails event". I am testing with CIQ 3.0.9, Fenix 5S 12.40 (CIQ 3.0.1), Android 8.0, GCM 4.15.1.

Does the period between sent messages have impact to this issue or the "100% fails event" will inevitably happen in some time in any case?
Is possible workaround to periodically download data from Garmin via makeWebRequest? Or is this failing too after while?
The solution mentioned by @Rob_B42 on the first page only solve throwing warning for that Key com.garmin.android.connectiq.EXTRA_REMOTE_DEVICE expected Long but value was a com.garmin.android.connectiq.IQDevice exception, right? I see it is thrown even when sending of message don't fail, so it can't be related.

I just run into this problem too and I hope I just didn't lost 2 months work and one of my clients… :eek: Thanks to anybody who will provide more light into this problem!

Jan Čapek over 5 years ago

Update: So according to another tests, not every time help to restart GCM or even all of its android services. This time it helped to have comm back to restart garmin device. But not sure, if this help in all cases yet.

On another hand, if I lower cadence of sending messages from 1 second to 3 second so far it seems that I don't get those random failures at all. Not sure, if that means that I don't reach that "100% fails event". I will see according to more tests.

EDIT: Yep, doesn't matter, the communication still keep failing without any possible way to make it work again from the app or android.

ArtaudAntonin / Jiri Richter over 5 years ago

I didn't try it myself but a friend has his app use the makeWebRequest workaround, with a nanoHTTPD server on the phone which he polls at localhost, and said there are no issues.
Of course, the issues are that you need to run a webserver on your phone, and the API calls you have to do are ugly as hell.

You have nicely summed up what I'm experiencing for the last two years. If you send enough messages in one session, you're almost inevitably headed for this issue. The Messaging API is unusable for any serious communication until a miracle happens on the GCM team I assume...

ArtaudAntonin / Jiri Richter over 5 years ago

Any news? Please, if no-one at Garmin cares about this, just tell us to not use the Comm API and please do not feed the false hopes...

@Stephen.ConnectIQ
@Coleman.ConnectIQ

marccardinal over 5 years ago

I am getting both issues described here with the most recent version of the SDKs.

The FAILURE_DURING_TRANSFER and

    java.lang.ClassCastException: com.garmin.android.connectiq.IQDevice cannot be cast to java.lang.Long
        at android.os.BaseBundle.getLong(BaseBundle.java:1070)
        at android.content.Intent.getLongExtra(Intent.java:8063)
        at com.garmin.android.connectiq.IQMessageReceiver.onReceive(IQMessageReceiver.java:134)

It looks like FAILURE_DURING_TRANSFER persists through phone and watch reboots, it disappears if I increase the interval between the messages from the phone to the watch from 1.0s to 1.5s.

I will look at the workaround regarding the java.lang.Long issue but it would be nice if anyone from Garmin can pitch in on this.