[Cloudflare One] Fix incorrect resolver selection description in resolver policies - #32601
Open
grstnhbr wants to merge 1 commit into
Open
[Cloudflare One] Fix incorrect resolver selection description in resolver policies#32601grstnhbr wants to merge 1 commit into
grstnhbr wants to merge 1 commit into
Conversation
Contributor
Review
👉 Fix in your agent 👈Fix the following review findings in PR #32601 (https://github.com/cloudflare/cloudflare-docs/pull/32601).
Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order
After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.
The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.
---
## Style Guide Review
### Warnings (1)
#### SG-323aa40cc09e · Directional words
- **File:** `src/content/partials/cloudflare-one/gateway/create-resolver-policy.mdx` line 81
- **Issue:** Line contains "Within each of the three above scenarios"
- **Fix:** Replace the directional word "above" with a direct reference, e.g., "Within each of these three scenarios" or "Within each of the three scenarios described earlier."
Code ReviewThis code review is in beta and may not always be helpful — use your judgment. No code review issues found. ConventionsNo convention issues found. Style Guide ReviewWarnings (1)
CommandsOnly codeowners can run commands. Post a comment with the command to trigger it.
|
…lver policies The documentation incorrectly stated that Gateway caches the fastest resolver for subsequent queries. In practice, Gateway selects a resolver at random using uniform traffic distribution within each category (public/private), and falls back to the next resolver based on round-trip time if the selected one does not respond.
grstnhbr
force-pushed
the
fix/resolver-policy-upstream-selection
branch
from
August 7, 2026 14:01
f5c2a12 to
d72afb4
Compare
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.
What
Fixes an inaccuracy in the resolver policies documentation. The docs stated that Gateway caches the fastest resolver for subsequent queries. This is not how the system works.
Actual behavior
Gateway selects a resolver at random using uniform traffic distribution within each category (public, private-default-vnet, private-custom-vnet). If the selected resolver does not respond in time, Gateway attempts the next resolver based on observed round-trip time. Queries are staggered, not sent all at once.
The FastServer algorithm exists in EdgeDNS but is not used by gateway-resolver for custom resolvers.
Change
In
src/content/partials/cloudflare-one/gateway/create-resolver-policy.mdx:Before:
After:
Context
This was identified by the Gateway engineering team during investigation of customer DNS resolution behavior with resolver policies.