Lambda Timeout

[grahamburgsma]

Describe the bug

Setting the timeout on Lambda doesn't have any effect if it's shorter than the connection timeout set by the HTTPClient. In other cases this makes sense, but since a Lambda doesn't respond until it's complete it hits the connection timeout, which is unexpected.

To Reproduce
Steps to reproduce the behavior:

1. Create Lambda client Lambda(...timeout: .seconds(300))
2. Invoke long running lambda function

It hits HTTPClientError.readTimeout at the default connectionTimeout of 90 seconds.

[adam-fowler]

The Soto service timeout is passed to HTTPClient. If the HTTPClient is not keeping to that timeout and applying a separate global timeout I'd say that's a bug in AsyncHTTPClient.

Out of interest where is this 90 second default?

[grahamburgsma]

Okay, did some more investigating. My previous assumption was wrong, it's not related to the connection timeout.

By default AWSClient uses HTTPClient.shared which sets a read timeout of 90 seconds. It seems like this overrides what's set by the AWSServiceConfig.

I've been able to get around this by using a new HTTPClient with no timeouts, so then it uses the timeout from the AWSServiceConfig.

app.aws.client = AWSClient(httpClient: HTTPClient(configuration: .init(timeout: .init())))

I think the default configuration for Soto should remove the HTTPClient read timeout. It took a fair bit of debugging to figure out why the timeout I set wasn't working!

[adam-fowler]

I added swift-server/async-http-client#825

I think the default configuration for Soto should remove the HTTPClient read timeout. It took a fair bit of debugging to figure out why the timeout I set wasn't working!

I can't change the HTTPClient read timeout as it would change the timeout for all modules that use that HTTPClient.

[grahamburgsma]

Nice, hopefully that gets addressed.

I can't change the HTTPClient read timeout as it would change the timeout for all modules that use that HTTPClient.

Sorry I was suggesting Soto not use the shared HTTPClient by default. But I don't know the disadvantages of that. Either way, if it's resolved by async-http-client then it's not problem!