Invalid IPProtocol value handling in chooseProtocol #1057
+27
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As a user, we got bitten by our configuration containing
ipv6
instead ofip6
(andipv4
). As a result, our probes to an IPv6 only host failed. This was harder to debug than expected because we did not understand why the probe defaulted toip_protocol=ip4
when we configured it for IPv6.There are multiple ways of fixing this. I thought the clear local improvement was to:
I realise that this is technically a breaking change because the behaviour on an invalid value changes from ip4 to ip6. Further work would be to reject invalid values when parsing the configuration, but that would be a real breaking change.