Description
Let's say the cluster_resolver LB policy receives two discovery mechanisms as part of its configuration: a higher priority EDS and a lower priority LOGICAL_DNS cluster. The cluster_resolver LB policy creates child policy configs only after both discovery mechanisms are resolved.
Let's specifically consider the case where the first EDS response for the higher priority EDS cluster is NACKed by the xDS client. This is handled by the edsDiscoveryMechanism here:
The error is propagated to the cluster_resolver LB policy by pushing it onto a channel here:
At this point, since the cluster_resolver has not created a child policy (because it has not received valid responses from both discovery mechanisms), it will report TransientFailure to its parent here:
Instead the cluster_resolver should treat this error from the xDS client as though it received an EDS response with a single priority and no localities. This will allow it to create the priority child (once it receives a response from the DNS mechanism as well), and will allow it to fail over to it.
Also, the cluster_resolver LB policy should do the same thing if the EDS watcher returns a resource-does-not-exist error. The only difference between a resource NACK error and a resource-does-not-exist error is that the former ignores the error if there was a previous result, whereas the latter does not.