core: Reset configSelector on realChannel while entering IDLE state

[kkalin68]

ManagedChannel will be stuck in IDLE state when xDS control plane doesn't have a resource anymore.
The scenario is following:

1. Channel is open for a xds resource.
2. XdsNameResolver subscribes to the resource on xDS control plane.
3. The resource is removed from xDS control plane for extended period of time (unhealthy for more than the idle timeout on Channel)
4. Channel enters into TRANSIENT_FAILURE
5. The Idle timeout triggers and Channel shutdowns XdsNameResolver and other resources. xDS watchers are removed.
6. The resource comes back online on xDS control plane.
7. A new GRPC call is executed targeting the channel.
8. The channel stays in IDLE state and reports: "io.grpc.StatusRuntimeException: UNAVAILABLE: LDS resource xxxx does not exist nodeID: yyyy" because realChannel.configSelector still points to old state.

public <ReqT, RespT> ClientCall<ReqT, RespT> newCall(
        MethodDescriptor<ReqT, RespT> method, CallOptions callOptions) {
      if (configSelector.get() != INITIAL_PENDING_SELECTOR) {
        return newClientCall(method, callOptions);
      }
...

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: kkalin68 / name: Konstantin Kalin (f09b7d9)

[AgraVator]

Hey,
Please fix the failing test cases. Thanks.

[Copilot]

Pull request overview

Fixes a ManagedChannel idle-mode edge case where a stale InternalConfigSelector can prevent the channel from properly exiting IDLE after xDS resources disappear and later reappear.

Changes:

• Reset realChannel’s config selector to INITIAL_PENDING_SELECTOR when entering IDLE, forcing the next call to trigger resolver/LB restart.
• Prevent pending-call reprocessing when updateConfigSelector() is called with INITIAL_PENDING_SELECTOR (only reprocess when transitioning away from the initial pending selector).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kkalin68]

Hey, Please fix the failing test cases. Thanks.

The tests are passing locally. Also the failures in tests(11) and tests(17) runs are unrelated to changes I made. And same tests passed in tests(8) and test(21). Also I don't see an option to retrigger the failed tests.

[kkalin68]

Is it anything else I should do to get the change reviewed ? We face this issue occasionally in production and it requires a service restart to reset GRPC channel

[kannanjgithub]

Is it anything else I should do to get the change reviewed ? We face this issue occasionally in production and it requires a service restart to reset GRPC channel

Can you address the Copilot review comment above for adding a new test?

[kkalin68]

Is it anything else I should do to get the change reviewed ? We face this issue occasionally in production and it requires a service restart to reset GRPC channel

Can you address the Copilot review comment above for adding a new test?

I added tests. Please note, I used Copilot to navigate and create the tests

[kkalin68]

Failed test(11) is not related to my changes. Same test passed for other Java versions

[kkalin68]

Is it anything else I should do to get the change reviewed ? We face this issue occasionally in production and it requires a service restart to reset GRPC channel

Can you address the Copilot review comment above for adding a new test?

Is there anything I should do to get this merged ?

[kkalin68]

@AgraVator Could you please take a look at the change ?

[AgraVator]

@AgraVator Could you please take a look at the change ?

Hey @kkalin68 feel free to merge as @kannanjgithub has already approved the changes

[kkalin68]

@AgraVator @kannanjgithub GH tells me I cannot merge since PR needs 2 reviewers and only one is approved. Or may be the issue is in failed build for Java 11.