-
Notifications
You must be signed in to change notification settings - Fork 0
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
fix: Only connect lazily (remove option to connect eagerly) #49
Conversation
Resolves: #43 Signed-off-by: Vaibhav Rabber <vaibhav@s2.dev>
src/client.rs
Outdated
@@ -561,7 +570,7 @@ impl ClientInner { | |||
)? | |||
.connect_timeout(config.connection_timeout) | |||
.timeout(config.request_timeout); | |||
let channel = if config.connect_lazily || force_lazy_connection { | |||
let channel = if config.connection_mode == ConnectionMode::Lazy || force_lazy_connection { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you see a way to avoid the bool for force_lazy_connection
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please also revisit the internal bools around this
I think I'd prefer if we just went with lazy, always.
Separately, let's consider ways in which we can clearly distinguish requests that were never transmitted due to failing at the connection stage, since those can be safely retried even if non-idempotent. |
ConnectionMode
enum
As a follow-up will take on looking at this. |
@infiniteregrets something to note here in this PR, the connect methods have been made sync now since we're connecting lazily. Moreover, maybe we should name them |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, let's rename to new
Re: #54 - I guess those methods should be called |
WRT #54, .keep_alive_timeout(Duration::from_secs(5))
.http2_keep_alive_interval(Duration::from_secs(5)) And it does not use a TLS config, which is used in the original connection: .tls_config(
ClientTlsConfig::default()
.with_webpki_roots()
.assume_http2(true),
)? Are these supposed to be different? I was thinking of combining the functions. Maybe we have a flag for TLS configuration and if required, configs for keep alive timeouts as well? |
The The key difference is we are using Re: |
I think I copied that directly from the endpoint config from the DST |
@infiniteregrets can you try this branch out once for your DST stuff? The connector stuff is still gated behind the feature but I have made the dependencies non-optional since they are already hard dependencies on tonic (at least for us). This makes the code a bit cleaner. |
src/client.rs
Outdated
#[cfg(feature = "connector")] | ||
#[error("Invalid basin zone: should be None when connecting with connector")] | ||
InvalidBasinZoneConnector, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think better to panic in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LG aside from avoiding a new error variant, any integration issue for the connector feature can be a followup
Resolves: #43