RUST-911: Add srvServiceName URI option #1235
Conversation
There was a problem hiding this comment.
looking good so far - we'll also need to implement the prose test described here
src/srv.rs
Outdated
| @@ -90,14 +94,21 @@ pub(crate) enum DomainMismatch { | |||
| #[cfg(feature = "dns-resolver")] | |||
| pub(crate) struct SrvResolver { | |||
| resolver: crate::runtime::AsyncResolver, | |||
| client_options: Option<ClientOptions>, | |||
There was a problem hiding this comment.
suggest only storing the service name rather than the entire options struct - it looks like that's the only field being accessed from this
src/srv.rs
Outdated
| .unwrap_or(default_service_name), | ||
| }; | ||
| let lookup_hostname = format!("_{}._tcp.{}", service_name, original_hostname); | ||
| .unwrap_or("mongodb".to_string()), |
There was a problem hiding this comment.
tiny style nit: we can do the following to avoid allocating an extra string here
self.srv_service_name
.as_deref() // converts into an Option<&str> to get a reference to the inner string
.unwrap_or("mongodb")
|
disregard my comment about assertions, I misread which method was being called! |
| async fn resolve( | ||
| self, | ||
| resolver_config: Option<ResolverConfig>, | ||
| srv_service_name: Option<String>, |
There was a problem hiding this comment.
Would it make sense to bundle srv_service_name into resolver_config? Mechanically, they're always passed around as a pair but I could see going either way on whether it's the right thing conceptually.
There was a problem hiding this comment.
Looked into this a bit, decided to keep it as is to reduce complexity in how the srv_service_name is passed through the codepath (from being parsed as part of the connection string down to the srv resolver- adding the parameter to ResolverConfig disrupts this a little bit). Thank you for pointing this out!
RUST-911