Skip to content

Store DNS answers in map instead of unordered map#24330

Closed
jwendell wants to merge 1 commit intoenvoyproxy:mainfrom
jwendell:fix-order
Closed

Store DNS answers in map instead of unordered map#24330
jwendell wants to merge 1 commit intoenvoyproxy:mainfrom
jwendell:fix-order

Conversation

@jwendell
Copy link
Copy Markdown
Member

@jwendell jwendell commented Dec 2, 2022

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:

// We shuffle the list of addresses when we read the config, and in the case of more than
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:

// Randomize the starting index if we have more than 8 records
) assumes on this behavior.

Signed-off-by: Jonh Wendell jwendell@redhat.com

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>
@jwendell
Copy link
Copy Markdown
Member Author

jwendell commented Dec 2, 2022

cc @abaptiste

Copy link
Copy Markdown
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
@github-actions
Copy link
Copy Markdown

github-actions bot commented Jan 4, 2023

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!

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Jan 4, 2023
@github-actions
Copy link
Copy Markdown

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!

@github-actions github-actions bot closed this Jan 11, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale stalebot believes this issue/PR has not been touched recently waiting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants