Does setting socket timeout cancel the initial request

Question

I have a request that can only run once. At times, the request takes much longer than it should.

If I were to set a default socket timeout value (using socket.setdefaulttimeout(5) ), and it took longer than 5 seconds, will the original request be cancelled so it's safe to retry (see example code below)?

If not, what is the best way to cancel the original request and retry it again ensuring it never runs more than once.

import socket
from googleapiclient.discovery import build
from tenacity import retry, stop_after_attempt, wait_fixed, retry_if_exception_type

@retry(
    retry=retry_if_exception_type(socket.timeout),
    wait=wait_fixed(4),
    stop=stop_after_attempt(3)
)
def create_file_once_only(creds, body):
    service = build('drive', 'v3', credentials=creds)
    file = service.files().create(body=body, fields='id').execute()

socket.setdefaulttimeout(5)
create_file_once_only(creds, body)

Answer 1

It's unlikely that this can be made to work as you hope. An HTTP POST (as with any other HTTP request) is implemented by sending a command to the web server, then receiving a response. The python requests library encapsulates a lot of tedious parts of that for you, but at the core, it's going to do a socket send followed by a socket recv (it may of course require more than one send or recv depending on the size of the data).

Now, if you were able to connect to the web server initially (again, this is taken care of for you by the requests library but typically only takes a few milliseconds), then it's highly likely that the data in your POST request has long since been sent. (If the data you are sending is megabytes long, it's possible that it's only been partially sent, but if it is reasonably short, it's almost certainly been sent in full.)

That in turn means that in all likelihood the server has received your entire request and is working on it or has enqueued your request to work on it eventually. In either case, even if you break the connection to the server by timing out on the recv , it's unlikely that the server will actually even notice that until it gets to the point in its execution where it would be sending its response to your request. By that point, it has probably finished doing whatever it was going to do.

In other words, your socket timeout is not going to apply to the "HTTP request" -- it applies to the underlying socket operations instead -- and almost certainly to the recv part on the tail end. And just breaking the socket connection doesn't cancel the HTTP request.

There is no reliable way to do what you want without designing a transactional protocol with the close cooperation of the HTTP server.

You could do something (with the cooperation of the HTTP server still) that could do something approximating it:

1. Create a unique ID (UUID or the like)
2. Send a request to the server that contains that UUID along with the other account info (name, password, whatever else)
3. The server then only creates the account if it hasn't already created an account with the same unique ID.

That way, you can request the operation multiple times, but know that it will only actually be implemented once. If asked to do the same operation a second time, the server would simply respond with "yep, already did that".