FAILURE_DURING_TRANSFER issue again (now using Comm sample )

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.

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

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

Hi, any news?

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!

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.

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...

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

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.