Why does HttpClient dispatch it's response callbacks on the main thread?

[erawhctim]

Not exactly a bug, per se, as it seems like very intentional behavior..... but it's caused some NetworkOnMainThreadExceptions that we've had to track down and debug through the SDK internals.

Are the responses dispatched on main just for convenience? Or some other reason?

[sshropshire]

Hey @erawhctim thinking back, it was mostly for convenience so merchants wouldn't have to worry about switching back to the main thread. I do feel that the current implementation is overly opinionated and we may want to alter this behavior in the future. We are in the process of migrating to Kotlin. Moving to coroutines would allow us to cleanly delegate the responsibility of thread scheduling to the caller.

At the same time I am surprised that a NetworkOnMainThreadException is thrown. We do have a ThreadScheduler class that allows HttpClient to execute the actual networking call on a background thread.

I am concerned now that the ExecutorService could possibly dispatch to main in some circumstances though. The documentation doesn't explicitly rule submission of a Runnable to main. Do you have more details on when this occurs? Or if it's frequent?

[erawhctim]

Moving to coroutines would allow us to cleanly delegate the responsibility of thread scheduling to the caller.

Totally agree! I think that rewrite is a great place to try and enhance this behavior 💯

The NetworkOnMainThreadException we ran into seems to stem from this bit here in the HttpClient.

[sshropshire]

Yeah the ExecutorService we create here seems like it could include the main thread in it's pool somehow. It's probably unlikely and the docs don't explicitly call out that it is possible, but they also don't say it's impossible.