Store DNS answers in map instead of unordered map#24330
Closed
jwendell wants to merge 1 commit intoenvoyproxy:mainfrom
Closed
Store DNS answers in map instead of unordered map#24330jwendell wants to merge 1 commit intoenvoyproxy:mainfrom
jwendell wants to merge 1 commit intoenvoyproxy:mainfrom
Conversation
The current code assumes the order when iterating over the map is the same as when elements are inserted. This is not true when using an unordered map. In particular there's one test that relies on this behavior: https://github.com/envoyproxy/envoy/blob/de2548820518e06b36a82e486cd13158f44abd31/test/extensions/filters/udp/dns_filter/dns_filter_test.cc#L1929 This test is always failing in my environment because the first entry of `response_ctx_->answers_` is always `"10.0.16.1"`. One possible solution would be to just remove that test as this behavior cannot be guaranteed. Not sure if this is the right thing to do as current code (e.g. here: https://github.com/envoyproxy/envoy/blob/de2548820518e06b36a82e486cd13158f44abd31/source/extensions/filters/udp/dns_filter/dns_parser.cc#L493) assumes on this behavior. Signed-off-by: Jonh Wendell <jwendell@redhat.com>
Member
Author
|
cc @abaptiste |
mattklein123
requested changes
Dec 5, 2022
Member
mattklein123
left a comment
There was a problem hiding this comment.
Thanks for the fix. I think we should fix the test instead of changing the product code.
/wait
jwendell
added a commit
to jwendell/envoy-1
that referenced
this pull request
Dec 12, 2022
It's always failing in our environment. Upstream bug: envoyproxy/envoy#24330
maistra-bot
pushed a commit
to maistra/envoy
that referenced
this pull request
Dec 12, 2022
It's always failing in our environment. Upstream bug: envoyproxy/envoy#24330
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
twghu
pushed a commit
to twghu/maistra-envoy
that referenced
this pull request
Feb 28, 2023
It's always failing in our environment. Upstream bug: envoyproxy/envoy#24330
twghu
pushed a commit
to twghu/maistra-envoy
that referenced
this pull request
Feb 28, 2023
It's always failing in our environment. Upstream bug: envoyproxy/envoy#24330
yanavlasov
added a commit
that referenced
this pull request
May 15, 2025
Use a different insertion and retrieval order into std::unordered_multimap. This fixes the problem where libstdc++ implementation starting in GCC13 always ends up producing the first address in the answer and causing the test to fail. Risk Level: Low Testing: Unit Test Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A Fixes #24330 Signed-off-by: Yan Avlasov <yavlasov@google.com>
fishpan1209
pushed a commit
to fishpan1209/envoy
that referenced
this pull request
May 22, 2025
…39464) Use a different insertion and retrieval order into std::unordered_multimap. This fixes the problem where libstdc++ implementation starting in GCC13 always ends up producing the first address in the answer and causing the test to fail. Risk Level: Low Testing: Unit Test Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A Fixes envoyproxy#24330 Signed-off-by: Yan Avlasov <yavlasov@google.com> Signed-off-by: Ting Pan <panting@google.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The current code assumes the order when iterating over the map is the same as when elements are inserted. This is not true when using an unordered map.
In particular there's one test that relies on this behavior:
envoy/test/extensions/filters/udp/dns_filter/dns_filter_test.cc
Line 1929 in de25488
response_ctx_->answers_is always"10.0.16.1".One possible solution would be to just remove that test as this behavior cannot be guaranteed. Not sure if this is the right thing to do as current code (e.g. here:
envoy/source/extensions/filters/udp/dns_filter/dns_parser.cc
Line 493 in de25488
Signed-off-by: Jonh Wendell jwendell@redhat.com