Make default: --cli-connect-timeout 6000

[LarryKlugerDS]

Is your feature request related to a problem? Please describe.
Problem: timeouts when using aws lambda update-function-code to upload zip file.
See the many problem reports: #3842 and StackOverflow

Describe the solution you'd like
Please make the option --cli-connect-timeout 6000 be a default option

Describe alternatives you've considered
Require devs with this problem to search for the answer. (Current situation.)

Additional context
Making this change will not slow anything down, it simply solves the not uncommon case of slow networking and proxies.

[kdaily]

Hi @LarryKlugerDS, I don't think that we would change the default for this, as many users may rely on connections timing out as they do. One thing that could be done is to improve the configurability of this value, as there is no environment variable or configuration file option for it.

[LarryKlugerDS]

Hi @kdaily , thank you for your reply. Perhaps add a short url in the timeout error message that would link to an article about adding this option?

Currently the error message just tells the developer what happened. But the best error messages also tell the person how to fix the problem.

Outside of the US the internet and connections to it are often quite slow. That's why you can see so many devs trying to figure out this problem. Let's help them....

[LarryKlugerDS]

Re:

many users may rely on connections timing out as they do

With this proposal, the connections would still time out, it would just take a little longer for them to do so. Remember that a connection timeout is by definition an error state. I suggest that waiting at little bit longer to enter that error state would not be an inconvenience to users.

Especially compared to the many users who don't want the error...

[mowliv]

Not just outside the U.S. :) ... witness all the rural U.S. interest in Starlink. There's lots of slow internet here, too.

…

On Thu, Nov 26, 2020 at 1:49 AM Larry Kluger ***@***.***> wrote: Hi @kdaily <https://github.com/kdaily> , thank you for your reply. Perhaps add a short url in the timeout error message that would link to an article about adding this option? Currently the error message just tells the developer *what* happened. But the best error messages also tell the person how to fix the problem. Outside of the US the internet and connections to it are often quite slow. That's why you can see so many devs trying to figure out this problem. Let's help them.... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5754 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDDXTMFVMNMWXNBKVV7U63SRYQBPANCNFSM4UCBJY3A> .

[abdennour]

me also ! same error :

Connection was closed before we received a valid response from endpoint URL:

However my case is different :
I am using Minio as hosted-s3.

• when i set the endpoint-url=http://localhost:9000 (port 9000 forward with kubectl port-forward), it does not work and it times out.
• when i set the endpoint-url=https://s3.example.com (thru ingress controller) , it works successfully

# ------------- ------------- ------------- -------------
k -n object-storage port-forward s3-minio-0 9000:9000 &
aws --endpoint-url=http://localhost:9000 s3api create-bucket --bucket bucket-from-aws-cli --acl public-read
#  Connection was closed before we received a valid response from endpoint URL: "http://localhost:9000/bucket-from-aws-cli".
# => it does work 
# ------------- ------------- ------------- -------------
aws --endpoint-url=https://s3.devops.example.com s3api create-bucket --bucket bucket-from-aws-cli --acl public-read
# {
#    "Location": "/bucket-from-aws-cli"
# }
# => it does NOT work