client: Change connectivity state to CONNECTING when creating the name resolver #8710

easwars · 2025-11-14T21:48:06Z

Fixes #7686

Current Behavior

When client exits IDLE and creates the name resolver, it stays in IDLE until the connectivity state is set by the LB policy.
When exiting IDLE mode (because of Connect being called or because of an RPC), if name resolver creation fails, we stay in IDLE.

New Behavior

When the client exits IDLE and creates the name resolver, it moves to CONNECTING. Moving forward, the connectivity state will be set by the LB policy.
When exiting IDLE mode (because of Connect being called or because of an RPC), we have already moved to CONNECTING (because of the previous bullet point). If name resolver creation fails, we will move to TRANSIENT_FAILURE and start the idle timer and move back to IDLE when the timer fires

RELEASE NOTES:

client: Change connectivity state to CONNECTING when creating the name resolver (as part of exiting IDLE).
client: Change connectivity state to TRANSIENT_FAILURE if name resolver creation fails.
client: Change connectivity state to IDLE after idle timeout expires (also when current state is TRANSIENT_FAILURE).

…resolver

codecov · 2025-11-14T21:51:17Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.20%. Comparing base (112ec12) to head (bd0ee2b).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8710      +/-   ##
==========================================
- Coverage   83.28%   83.20%   -0.09%     
==========================================
  Files         416      419       +3     
  Lines       32267    32431     +164     
==========================================
+ Hits        26874    26983     +109     
- Misses       4019     4061      +42     
- Partials     1374     1387      +13

Files with missing lines	Coverage Δ
clientconn.go	`90.54% <100.00%> (+0.40%)`	⬆️
internal/idle/idle.go	`89.28% <100.00%> (+0.12%)`	⬆️
resolver_wrapper.go	`92.45% <ø> (ø)`

... and 27 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

dfawley · 2025-11-20T22:11:20Z

dial_test.go


 func (s stringerVal) String() string { return s.s }
+
+const errResolverBuildercheme = "test-resolver-build-failure"


dfawley · 2025-11-20T22:27:38Z

resolver_wrapper.go

+		// https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md
+		// defines CONNECTING as follows:
+		// - The channel is trying to establish a connection and is waiting to
+		//   make progress on one of the steps involved in name resolution, TCP
+		//   connection establishment or TLS handshake. This may be used as the
+		//   initial state for channels upon creation.
+		//
+		// We are starting the name resolver here as part of exiting IDLE, so
+		// transitioning to CONNECTING is the right thing to do.


IMO comments should be short and to the point.

Short comments make the code take up less space, which makes it easier to read and understand. Long comments make long functions extremely long and not fit on the page.

Honestly, I think a comment for this action isn't even necessary. But if you think we need one, this could be:

// Set state to CONNECTING before building the name resolver // so the channel does not remain in IDLE.

dfawley · 2025-11-20T22:33:09Z

test/clientconn_state_transition_test.go

+			if state := cc.GetState(); state != connectivity.Idle {
+				t.Fatalf("Expected initial state to be IDLE, got %v", state)
+			}


The AwaitState above already tested this IIUC

dfawley · 2025-11-20T22:33:59Z

test/clientconn_state_transition_test.go

+			// Ensure that the client is in IDLE before connecting.
+			ctx, cancel := context.WithTimeout(context.Background(), defaultTestTimeout)
+			defer cancel()
+			testutils.AwaitState(ctx, t, cc, connectivity.Idle)


This doesn't need an Await right? It should just check the current state, and never wait for changes, as we know it starts idle.

That's true. Moved the check for the current state to here, and got rid of the Await.

dfawley · 2025-11-20T22:35:18Z

test/clientconn_state_transition_test.go

+			for _, wantState := range wantStates {
+				waitForState(ctx, t, stateCh, wantState)
+				if wantState == connectivity.Idle {
+					tt.exitIdleFunc(ctx, cc)


Can we make this test the actual RPC error when we use an RPC to exit idle?

Done. I changed the test a little to make that happen.

But as part of doing that, I realized a thing or two:

The RPC is not failing with a status error, because the idle.Manager.ExitIdleMode which is called when an RPC has to kick the channel out of IDLE, does not embed the error returned from ClientConn.ExitIdleMode. But if we make it embed the error, we will have to return a status error from the latter, which is doable. But that brings the following questions:

What code do we return? I'm torn between Unavailable and Internal, and leaning towards the latter

This would also make Dial fail with a status error which I find a little odd.

Thoughts?

Maybe Unavailable and then it's treated the same as if the resolver did a ReportError immediately instead of failing to build? But probably we should see what the C++/Java lame/failing channels do before deciding, since that seems like the most equivalent scenario in languages where the resolver can't fail to build -- it just doesn't exist.

dfawley · 2025-11-20T22:36:44Z

resolver_wrapper.go

+		//
+		// We are starting the name resolver here as part of exiting IDLE, so
+		// transitioning to CONNECTING is the right thing to do.
+		ccr.cc.csMgr.updateState(connectivity.Connecting)


Could this (and the error handling below) go into exitIdleMode instead? It might make more sense to be in the channel directly, rather than in this sub-component.

client: move connectivity state to CONNECTING when creating the name …

1cb398d

…resolver

easwars requested a review from dfawley November 14, 2025 21:48

easwars assigned dfawley Nov 14, 2025

easwars added Type: Bug Area: Client Includes Channel/Subchannel/Streams, Connectivity States, RPC Retries, Dial/Call Options and more. labels Nov 14, 2025

easwars added this to the 1.78 Release milestone Nov 14, 2025

easwars requested a review from arjan-bal November 14, 2025 21:48

easwars assigned arjan-bal Nov 14, 2025

make vet happy

86503d2

dfawley reviewed Nov 20, 2025

View reviewed changes

easwars added 4 commits November 21, 2025 07:10

fix typo

f496de6

shorten comment, move error handling and setting state to the channel

36f14e6

check for IDLE after channel creation without awaiting

0131893

ensure resolver build error is returned to RPC

bd0ee2b


		func (s stringerVal) String() string { return s.s }

		const errResolverBuildercheme = "test-resolver-build-failure"

client: Change connectivity state to CONNECTING when creating the name resolver #8710

Are you sure you want to change the base?

client: Change connectivity state to CONNECTING when creating the name resolver #8710

Conversation

easwars commented Nov 14, 2025

Current Behavior

New Behavior

Uh oh!

codecov bot commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov bot commented Nov 14, 2025 •

edited

Loading