HDDS-8364. ReadReplicas may give wrong results with topology-aware read enabled #4522
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 changes were proposed in this pull request?
Due to same root cause as HDDS-8276,
ozone debug read-replicasmay give wrong results with topology-aware read enabled. It creates a single-node copy of the original pipeline for each replica, but only updatesnodes, notnodesInOrder. If the replica is stale (offline but not yet dead), read is attempted and fails, and the client checks if there are any fallback nodes. There should be none left (single-node pipeline), but with topology-aware read enabled the other two nodes are still present in the list.This PR moves the fix that was originally added for EC file checksum to the pipeline copy builder, so that all usages get fixed (currently only these two cases change nodes in the copy pipeline).
https://issues.apache.org/jira/browse/HDDS-8364
How was this patch tested?
Updated relevant smoketest to enable topology-aware read for this command, ran locally.
Ran
TestOzoneFileChecksumfor regression.CI:
https://github.com/adoroszlai/hadoop-ozone/actions/runs/4598039439