Some new data fields were added to the interface that had been called before due to the new business overlay. Later, when I was debugging the interface again, the following exception occurred when the request waiting was delayed until the timeout was set:

[discovery] errors encountered while discovering extensions: 
            Error Domain=PlugInKit Code=13 "query cancelled" 
            UserInfo={NSLocalizedDescription=query cancelled}

Task <C0BF69B6-6E49-44ED-B1E1-3E03212496EE>.<1> finished with error - code: -1001
Task <C0BF69B6-6E49-44ED-B1E1-3E03212496EE>.<1> load failed with error Error 
      Domain=NSURLErrorDomain 
      Code=-1001 "The request timed out." 
      UserInfo={_kCFStreamErrorCodeKey=-2102, 
                NSUnderlyingError=0x6000011ad8f0 {Error Domain=kCFErrorDomainCFNetwork 
                                                  Code=-1001 "(null)" 
                                                  UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}
                }, 
      _NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <C0BF69B6-6E49-44ED-B1E1-3E03212496EE>.
<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalUploadTask <C0BF69B6-6E49-44ED-B1E1-3E03212496EE>.<1>"), 
     NSLocalizedDescription=The request timed out., 
     NSErrorFailingURLStringKey=https://testEnvironment.xxx.org.cn/cres-api/api/account/app/2a258832847d3c8669755bae6c415b, 
     NSErrorFailingURLKey=https://testEnvironment.xxx.org.cn/uums-api/api/account/app/2a258832847d3c8669755bae6c415b, 
     _kCFStreamErrorDomainKey=4} [-1001]

First of all, from the appearance, I initially suspected that the account timeliness had expired and the authentication of the server had not passed, so I tried to log in the account again, submit the modification again and initiate the request, but still threw back the above exception. Then confirm with the server that the service is in a normal state of activation. Since the interface also has a call somewhere else, it tries to go to another page to make a request for what… Callback successful OMG…
second, start to find the cause of the problem again, because both places need to call the interface, the request method is already packaged for two separate calls, all since there is a business can be successfully called, first of all, eliminate the problem of method packaging;
secondly, because there are some new fields in the new business logic, the interface state is also in normal state before the new fields are added, then try whether there is a correlation between them in turn. After deleting some fields, try to initiate the request again, and receive the callback state in seconds… A flash of insight seems to get something going on, so keep trying this way;
finally, it was found that the callback status could not be returned before the request timeoutInterval due to the server mailbox field validation taking too long. The interface was judged as timeout exception handling by default… After relaxing the timeout period again, it was found that the data could be normally received, but the duration was longer… After feedback to the server for optimization, we have solved…
 
The solution
It’s a little bit more about troubleshooting, but the process of fumbling is interesting;
through the above analysis, the solution is as follows:
1. 2. Try to delay the timeout of timeoutInterval to try whether the interface callback state can be received normally; 3. The server checks whether there is a long validation or similar related business logic in the fields transmitted in the receiving front end, which leads to the slow callback time and ultimately the request timeout.

---

That’s all we have to share. There are a variety of exceptions and there may still be exceptions that are not covered. Please add more