Avoid log warning for tls_context if the user didn't set it #365
Conversation
set it. Fixes envoyproxy#364 Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
source/client/options_impl.cc
Outdated
| // Only set the tls context if it looks non-empty, to avoid a warning being logged about field | ||
| // deprecation. Ideally this would follow the way transport_socket uses absl::optional below. | ||
| // But as this field is about to get eliminated this minimal effort shortcut may be more suitable. | ||
| if (!Envoy::MessageUtil()(tls_context_, |
There was a problem hiding this comment.
Can we add a comment explaining how we are using Envoy::MessageUtil to verify that the tls_context_ message is non-empty?
(optional) On another note - isn't there a more direct way of checking if it is non-empty? E.g. proto2 used to have a method that could be used for that - my_proto.ByteSizeLong() == 0. However that call tends to be very inefficient on messages with many nested fields and I am unsure if it works in proto3 also.
There was a problem hiding this comment.
I found that theres also Envoy::Protobuf::util::MessageDifferencer::Equivalent these days, which I think is easier to grok. See 6b8a088, does that look better?
mum4k
added
waiting-for-changes
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
oschaaf
added
waiting-for-review
source/client/options_impl.cc
Outdated
| // But as this field is about to get eliminated this minimal effort shortcut may be more suitable. | ||
| if (!Envoy::MessageUtil()(tls_context_, | ||
| envoy::extensions::transport_sockets::tls::v3::UpstreamTlsContext())) { | ||
| if (!Envoy::Protobuf::util::MessageDifferencer::Equivalent( |
There was a problem hiding this comment.
Note - equivalent is not the same as equal. This would say that two messages are the same if one has a value set to zero and the other one has it unset where the default is zero.
Considering we are using this to determine if the message is unset, is that behavior desired?
There was a problem hiding this comment.
That is a good catch, thanks. Thinking this through, you're right, this isn't what we need here. I switched this to use the ByteSizeLong() method you pointed out. I'm not super concerned about it not being the fastest way to pull this off, as it is going to be eliminated at some point. Plus this isn't in the hot path. Addressed in f467e86
mum4k
added
waiting-for-changes
Signed-off-by: Otto van der Schaaf <oschaaf@we-amp.com>
oschaaf
added
waiting-for-review
Fixes #364
Signed-off-by: Otto van der Schaaf oschaaf@we-amp.com