UnityWebRequests on iOS sometimes get stuck indefinitely even with timeout set

Hello,

Using the latest Unity 2020.1.14f1 and iOS 14.2 unitywebrequests sometimes seem to get ‘stuck’ indefinitely, even with the timeout set to a low number (stuck meaning the ‘isDone’ property never returns true).

Here’s a test case, this will sometimes keep printing “Awaiting request” indefinitely, eventhough the timeout is set to 5:

internal IEnumerator AwaitRequest(UnityWebRequest request, Action<bool> result, Action<UnityWebRequest, ulong> percentage)
        {
            request.timeout = 5;
            request.SendWebRequest();

            while (!request.isDone)
            {
                Debug.LogFormat("Awaiting request {0} with timeout {1}", request.uri, request.timeout);
                yield return new WaitForSeconds(1f);
            }

            if (!request.isNetworkError && !request.isHttpError)
            {
                PlayerPrefs.SetString(request.url, request.downloadHandler.text);
                result?.Invoke(true);
            }
            else
            {
                if (request.responseCode == 400)
                {
                    PlayerPrefs.SetString(request.url, "{}");
                    result?.Invoke(true);
                }
                else
                    result?.Invoke(false);
            }
        }
1 Like

Are there any other information? Such as perhaps you have connectivity issues?

Nothing in xcode logs, no connectivity issues. This is a signed request to an AWS endpoint.

The webrequest is constructed like this:

UnityWebRequest getRequest = UnityWebRequest.Get(uri);

Since it fetches data from a private AWS endpoint, we then set some custom headers:

X-Amz-Content-SHA256
X-Amz-Date
Authorization

Confirmed on iPhone SE (gen1), iPhone 12 Pro, iPhone XR, iOS 14.2 and 14.2.1

I meet this issue too. Unity 2019.4.2f, IOS14.2.
I can’t get the response from this request forever.
It will happend occasionally.

Here is my code.

_unityWebRequest = new UnityWebRequest(requestUrl, UnityWebRequest.kHttpVerbPOST);
_unityWebRequest.timeout = RequestTimeout;
            _unityWebRequest.downloadHandler = new DownloadHandlerBuffer();
_unityWebRequest.SendWebRequest().completed += (AsyncOperation) => {
    Debug.Log("Receive");
};

@Aurimas-Cernius sorry to ping you directly about this, but we are getting reports about this by a lot of iOS testers

I’m not 100% confident, but this may only occur when fetching from the same endoint twice in the same app session

found some juicy infos in the log

2020-11-27 13:16:44.804684+0100 holomeet[8635:1095603] Connection 16: received failure notification
2020-11-27 13:16:44.804960+0100 holomeet[8635:1095603] Connection 16: failed to connect 3:-9816, reason -1
2020-11-27 13:16:44.805951+0100 holomeet[8635:1095603] Connection 16: encountered error(3:-9816)
2020-11-27 13:16:44.893798+0100 holomeet[8635:1095603] Task <11E02759-EA2E-4457-988B-B3CD0711BA5A>.<28> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])

Can you somewhat reliably reproduce it, or is it a failure in the wild?
You can try adding some additional logging in UnityWebRequest.mm file for additional info gathering.

I can consistently reproducte this across devices and recent ios versions

I would be most interested to know why a request that has a timeout x doesn’t auto-abort if a response hasn’t been received by then.

The way I see it there are 2 separate issues (from a usability standpoint), correct me if i’m wrong:

  • A subsequent request to an endpoint doesn’t always return a response
  • Setting a timeout doesn’t guarantee the request is aborted when the timeout is reached

in UnityWebRequest.mm the timeOutinterval is set:

UnityURLRequest* request = ([B]__bridge[/B] UnityURLRequest*)connection;
request.timeoutInterval = timeoutSec;

UnityURLRequest is an implementation of NSMutableURLRequest, so I’m guessing it uses that underlying logic to handle timeouts on the basis of the value set in c#.

So, reading into the the timeoutInterval property of the URLRequest it says this:

The "idle
    interval" is defined as the period of time that has passed since the
    last instance of load activity occurred for a request that is in the
    process of loading. Hence, when an instance of load activity occurs
    (e.g. bytes are received from the network for a request), the idle
    interval for a request is reset to 0.

This indicates the timeout resets when any kind of activity occurs.

your own documentation says something else

https://docs.unity3d.com/ScriptReference/Networking.UnityWebRequest-timeout.html

this indicates the request aborts if a time interval is reached, even if there’s been activity in the meantime

Can I somehow subscribe to the timeout event (if there is one) on the native side, to see if it fires?

We have our own internal timeout tracking as well, but it relies on activity from that Objective-C code (calling one of the callbacks).
When timeout happens I believe didCompleteWithError should be called.
What you experience is a symptom of Obj-C side finishing but not calling back to Unity.

If you can reproduce this reliably, please report a bug with repro project.

Seems like we’re facing the same problem

We havent yet found the cause, nor have we been able to make a 100 percent reliable reproduction case

same, it’s kinda random, sometimes it works, sometimes it takes forever to return with timeout, even though we explicitly set the timeout to 10 seconds

Same here… we’re having the EXACT same issue (only on 14.2, hard to reproduce, no timeout, no isDone status). We get it more often on the iPhoneX.

We’ve created our own time-out process so that, when we don’t have a UnityWebRequest.isDone we try to resend the UnityWebRequest. But once it’s broken… it’s broken for good.

Can you reproduce it at a reasonable rate? If so, please report a bug with a repro project.

We’re experiencing the same issue with UnityWebRequest calls in our app, on iOS 14. Similar errors in our log as others have reported. Also tried to implement on own timeout if we see that the connection stalls, but re-trying the request produces the same failure.

2020-12-08 11:41:11.164205-0500 coreApp[3077:182352] [tcp] tcp_output [C14.1:3] flags=[R.] seq=1572399593, ack=1585269364, win=8191 state=CLOSED rcv_nxt=1585269364, snd_una=1572399593
2020-12-08 11:41:11.165343-0500 coreApp[3077:182352] Connection 14: received failure notification
2020-12-08 11:41:11.165432-0500 coreApp[3077:182352] Connection 14: failed to connect 3:-9816, reason -1
2020-12-08 11:41:11.165460-0500 coreApp[3077:182352] Connection 14: encountered error(3:-9816)
2020-12-08 11:41:11.167284-0500 coreApp[3077:182352] Task <49BD9E09-6C4E-4BAE-BABB-63904A290614>.<16> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])
2020-12-08 11:41:11.315431-0500 coreApp[3077:182354] [tcp] tcp_output [C15.1:3] flags=[R.] seq=1360238599, ack=1453406931, win=8191 state=CLOSED rcv_nxt=1453406931, snd_una=1360238599
2020-12-08 11:41:11.316850-0500 coreApp[3077:182354] Connection 15: received failure notification
2020-12-08 11:41:11.317008-0500 coreApp[3077:182354] Connection 15: failed to connect 3:-9816, reason -1
2020-12-08 11:41:11.317047-0500 coreApp[3077:182354] Connection 15: encountered error(3:-9816)
2020-12-08 11:41:11.317828-0500 coreApp[3077:182354] Task <9A4C7C55-5F06-420A-9AB0-3B3183ABC88C>.<17> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])
2 Likes

Same issue here is some additional logs…

2020-12-08 11:41:11.164205-0500 app[3077:182352] [tcp] tcp_output [C14.1:3] flags=[R.] seq=1572399593, ack=1585269364, win=8191 state=CLOSED rcv_nxt=1585269364, snd_una=1572399593
2020-12-08 11:41:11.165343-0500 app[3077:182352] Connection 14: received failure notification
2020-12-08 11:41:11.165432-0500 app[3077:182352] Connection 14: failed to connect 3:-9816, reason -1
2020-12-08 11:41:11.165460-0500 app[3077:182352] Connection 14: encountered error(3:-9816)
2020-12-08 11:41:11.167284-0500 app[3077:182352] Task <49BD9E09-6C4E-4BAE-BABB-63904A290614>.<16> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])
2020-12-08 11:41:11.315431-0500 app[3077:182354] [tcp] tcp_output [C15.1:3] flags=[R.] seq=1360238599, ack=1453406931, win=8191 state=CLOSED rcv_nxt=1453406931, snd_una=1360238599
2020-12-08 11:41:11.316850-0500 app[3077:182354] Connection 15: received failure notification
2020-12-08 11:41:11.317008-0500 app[3077:182354] Connection 15: failed to connect 3:-9816, reason -1
2020-12-08 11:41:11.317047-0500 app[3077:182354] Connection 15: encountered error(3:-9816)
2020-12-08 11:41:11.317828-0500 app[3077:182354] Task <9A4C7C55-5F06-420A-9AB0-3B3183ABC88C>.<17> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9816])
1 Like

Same issue

1 Like

Some news?
Perhaps something related exclusively to the ios version 14.2. The same app works for me in version 14.1.

i’ve tried to make a reproduction project but haven’t yet been able to come up with something, it might be related to high memory usage

OK OK OK, thats the question: Are you all using AR Foundation!? I’ve replicated that, seems! Closing ArFoundation and reopening it. Now I have to understand if is my fault(some code error) or not.
May it be the right way?