kotlinlang #kotlin-fuel

Before we had the Bubble; the issue was that we could not reproduce anything, because we would only see some obscure error with a strack trace that had nothing to do with the actual issue. I haven't thought of a great merge of the two!

itnoles

05/03/2019, 7:32 PM

Now, we get null from BubbleFuelError with most difficult where it coming from.

itnoles

05/03/2019, 7:38 PM

it sounds like race conditions on the blocking requests

itnoles

05/03/2019, 7:48 PM

Good thing, we are not using Android Studio for this. 🙂

😋 1

itnoles

05/03/2019, 9:11 PM

Android Studio 3.4 lagging so bad, it eat your RAM like it was nothing.

itnoles

05/04/2019, 12:09 AM

@kittinunf would it be easier to do coroutines only?

kittinunf

05/05/2019, 6:28 AM

What does it mean by that?

Derk-Jan Karrenbeld

05/05/2019, 9:44 AM

He means dropping all the other async stuff I think

itnoles

05/05/2019, 6:11 PM

We could make Fuel as coroutines-based HTTP Client.

kittinunf

05/06/2019, 8:14 AM

I have investigated a bit on https://github.com/kittinunf/fuel/issues/606 and found out that we kinda double-wrap the

BubbleFuelError

kittinunf

05/06/2019, 8:15 AM

it looks like

kittinunf

05/06/2019, 8:15 AM

we wrap the exception once here

RequestTask.kt

kittinunf

05/06/2019, 8:15 AM

Copy code

runCatching { Pair(request, client.executeRequest(request)) }
            .recover { error ->
                throw FuelError.wrap(error, Response(request.url))
            }
            .getOrThrow()

kittinunf

05/06/2019, 8:15 AM

Then it got wrapped again here

Deserializable.kt

kittinunf

05/06/2019, 8:16 AM

Copy code

.onFailure { error ->
            FuelError.wrap(error, Response.error(url)).also {
                return Triple(this, it.response, Result.error(it))
            }
        }

Derk-Jan Karrenbeld

05/06/2019, 11:15 AM

Ugh. Perphaps we remove the first one?

Derk-Jan Karrenbeld

05/06/2019, 11:16 AM

I don't know if that breaks things. I'm pretty sure I needed both at some point, but that might have been resolved already

kittinunf

05/06/2019, 1:39 PM

I think we need both still …

kittinunf

05/06/2019, 1:39 PM

the first one is for the exception that is throwing from

client.executeRequest

itself

kittinunf

05/06/2019, 1:40 PM

the below one, we need it there for the

deserialization

Derk-Jan Karrenbeld

05/06/2019, 2:10 PM

Yesh that's how I wrote it I think

Derk-Jan Karrenbeld

05/06/2019, 2:11 PM

I think we should fail hard if we pass NULL as an error I guess

Derk-Jan Karrenbeld

05/06/2019, 2:11 PM

Oh you know what might be the issue?

Derk-Jan Karrenbeld

05/06/2019, 2:11 PM

I think it might be this case: - they ask for a response object of type T - the server returns an error, but not a body - because there is no body it's reporting NULL as the error message - the status code here is swallowed; it should have been wrapped in an http status error tho...

kittinunf

05/06/2019, 3:32 PM

🤔

kittinunf

05/06/2019, 3:33 PM

when I checked the

android.os.NetworkOnMainThreadException

, the

message

property is

null

though

kittinunf

05/06/2019, 3:34 PM

this is why when we print the

Result

it is

Failure: com.github.kittinunf.fuel.core.BubbleFuelError: null

kittinunf

05/06/2019, 3:38 PM

@Derk-Jan Karrenbeld what do you think about just returning the

FuelError

without the

BubbleFuelError

by doing this?