Timeout value is defined but not honored

[briandeanda]

For example, if I set a timeout of 2000, the network call does not error out and xhr.ontimeout is never called. When I log the values of init i can see that timeout is defined, I can also see that the xhr.timeout is set. This happens on a Motorola Moto E2 Android 5.1, API 22 with React Native 0.45.1

[cikai]

@briandeanda I have the same problems, timeout xhr.onerror is only called when I change my network status, for example, close wifi or switch to other wifi .

[dcarrot2]

@cikai Keep us updated if you find a workaround.

[vipcxj]

facing the same problem!

[rafkhan]

Does this only happen on android?

[pstanton]

+1 running android on galaxy s5

[pstanton]

I think XMLHttpRequest is implemented by react native and doesn't support the timeout feature. Therefore, a different mechanism is required to add timeout. Therefore this project is X|

[pstanton]

a working solution: https://github.com/github/fetch/issues/175#issuecomment-125779262

[atticoos]

I've had trouble reproducing this and could use help tackling it down and curious if later versions of React Native. I'm a bit at a loss, as timeouts have been supported natively since v0.19

@pstanton:

I think XMLHttpRequest is implemented by react native and doesn't support the timeout feature. Therefore, a different mechanism is required to add timeout. Therefore this project is X|

Yes, while React Native does implement XMLHttpRequest, it accepts a timeout and provides that to the native APIs (iOS, Android)

a working solution: https://github.com/github/fetch/issues/175#issuecomment-125779262

The downside of https://github.com/github/fetch/issues/175#issuecomment-125779262 is that it doesn't cancel the corresponding native request http request. Rather, on the client side, it just rejects the caller's promise. While it can be considered a work around if you aren't concerned by that, it's not a true timeout that many of us are looking for.

[pstanton]

Hi Aj, thanks for the attention. I'm currently using "react-native": "0.51.0" and a samsung galaxy s5 to test over adb (usb cable).

that is running android 7.0

I've tested with and without the chrome debugger attached (this can change behaviour).

Agree with downside of wrapping a timeout. A better solution would be great. If the http request is never cancelled, and never times out, is that an open socket until the app is completely closed?

personally i can't believe this very basic feature is missing from the stack! hence why so many projects like yours exist.

would be great if i can get it to work. cheers!

[atticoos]

Thanks for the environment info 👍

If the http request is never cancelled, and never times out, is that an open socket until the app is completely closed?

There's supposed to be a global default timeout on all connections. However, we were running an earlier version of React Native when putting this together because we noticed requests seemed to hang indefinitely, and then during a network change event, they would then all come back and resolve/reject.

[ithieund]

Maybe I faced with the same problem.

• When I fetch a right url, the timeout with 10 seconds works OK
• But when I try with incorrect url, the request hangs for a long time (2 or 3 mins) and finally return with error message in the console: 'HTTP error:', [TypeError: Network request failed]

How can we make this case jump into catch() after timeout was reached?

[TuurDutoit]

I was faced with the same issue, and after a long search I found out what was going wrong. The timeout option that React Native provides for XMLHttpRequest (which is used under the hood by this package), is actually a connect timeout, i.e. it is the time from the moment that the request was dispatched (the fetch() call) and the moment that the TCP connection was established. From that point on, the timeout is no longer relevant. In other words, React Native will wait for the server's response as long as needed, essentially ignoring the timeout option, as long as the initial TCP connection succeeded within the timeout duration.

This is at least true for Android - I think the iOS implementation is more sensible, but I didn't investigate further.