Skip to content

Fix connect_timeout for wasi-http #8085

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Mar 12, 2024

Conversation

rikhuijzer
Copy link
Contributor

@elliottt in #7356 mentions that connect_timeout, first_byte_timeout, and between_bytes_timeout should be tested.

This PR adds a test for connect_timeout and ensures that TcpStream::connect adheres to the timeout. Without this fix, setting connect_timeout has no effect on hosts where TcpStream::connect tries to connect.

Note that the variable connect_timeout is also used a bit later for the handshake:

let (sender, conn) = timeout(
connect_timeout,
hyper::client::conn::http1::handshake(stream),
)
.await
.map_err(|_| types::ErrorCode::ConnectionTimeout)?
.map_err(hyper_request_error)?;

I'm not sure whether using this variable twice is correct.

@rikhuijzer rikhuijzer requested a review from a team as a code owner March 12, 2024 08:01
@rikhuijzer rikhuijzer requested review from alexcrichton and removed request for a team March 12, 2024 08:01
Copy link
Member

@elliottt elliottt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, thank you!

Comment on lines +26 to +32
assert!(
matches!(
res.unwrap_err().downcast_ref::<ErrorCode>(),
Some(ErrorCode::ConnectionTimeout)
),
"expected connection timeout"
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for matching the timeout explicitly here!

@elliottt
Copy link
Member

I'm not sure whether using this variable twice is correct.

I see two uses in the handler function, but they're under different branches of the same conditional. Was there another use of connect_timeout that you were thinking of?

@rikhuijzer
Copy link
Contributor Author

This looks great, thank you!

Thanks for the review!

I'm not sure whether using this variable twice is correct.

I see two uses in the handler function, but they're under different branches of the same conditional. Was there another use of connect_timeout that you were thinking of?

There should be three (https://github.com/bytecodealliance/wasmtime/blob/eebce11eb1fdfc67ab8fc7a06cb68ba1231dd7a6/crates/wasi-http/src/types.rs).

One is now newly added near the TcpStream::connect and the other two are inside the branches near hyper::client::conn::http1::handshake. I think these two different phases represent TCP's SYN and ACK.

Why I mentioned it is because it sounded a bit weird to me that the connect_timeout is used twice, but on second thought maybe it's fine. The SYN and ACK are both still during the "Connection establishment" phase.

@elliottt
Copy link
Member

Ah! Sorry for misunderstanding. I think this is fine to leave it this way, but I agree that it's a little odd. Reading through the handshake implementation, it's assuming that the connection has already been made, so if anything we might want to remove the timeout on the second two uses in the function.

@elliottt
Copy link
Member

I added #8104 to record the fact that we should look into removing the uses of connect_timeout on the handshake calls, but that issue won't be valid until this PR merges.

@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 12, 2024
@elliottt elliottt added this pull request to the merge queue Mar 12, 2024
Merged via the queue into bytecodealliance:main with commit d29b863 Mar 12, 2024
@rikhuijzer rikhuijzer deleted the rh/wasi-http-timeout branch March 12, 2024 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants