internal/xds: change xds_resolver to use dependency manager #8711

eshitachandwani · 2025-11-17T03:20:56Z

This change is part of A74 implementation.

This PR removes the listener and route watchers from resolver and changes it so that we get the resources from xds dependency manager.

RELEASE NOTES: N/A

codecov · 2025-11-17T03:23:56Z

Codecov Report

❌ Patch coverage is 79.31034% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.40%. Comparing base (76c67d1) to head (3f87474).

Files with missing lines	Patch %	Lines
internal/xds/resolver/xds_resolver.go	76.00%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8711      +/-   ##
==========================================
+ Coverage   83.32%   83.40%   +0.07%     
==========================================
  Files         419      418       -1     
  Lines       32427    32331      -96     
==========================================
- Hits        27021    26966      -55     
+ Misses       4033     4006      -27     
+ Partials     1373     1359      -14

Files with missing lines	Coverage Δ
...ernal/xds/clients/xdsclient/clientimpl_watchers.go	`93.54% <100.00%> (+0.44%)`	⬆️
internal/xds/resolver/xds_resolver.go	`89.71% <76.00%> (+7.28%)`	⬆️

... and 21 files with indirect coverage changes

🚀 New features to boost your workflow:

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

arjan-bal · 2025-11-17T05:59:27Z

internal/xds/xdsdepmgr/xds_dependency_manager.go

-	// All the fields below are protected by mu.
-	mu      sync.Mutex
-	stopped bool
+	// All the fields below are accessed only from the callback serializer.
+	serializer       *grpcsync.CallbackSerializer
+	serializerCancel context.CancelFunc


Based on the PR description, this is being done because the XDS client is calling back into the watcher while the watcher is being registered. Can we fix by instead having the xDS client use it's serializer to schedule a call?

c.serializer.TrySchedule(func(context.Context) { watcher.ResourceError(fmt.Errorf("authority %q not found in bootstrap config for resource %q", n.Authority, resourceName), func() {}) })

Right! Changed.

easwars · 2025-11-17T23:28:12Z

Is the PR description out of date? I don't see any changes about switching the dependency manager to use the serializer again.

easwars · 2025-11-17T23:00:49Z

internal/xds/resolver/xds_resolver_test.go

 	}
 }

-// Tests the case where a resource, present in cache, returned by the


Is it possible to continue to test this scenario here? Or is this completely covered by tests in the dependency manager? I guess if there is an ambient error (with the dependency manager in the picture), that error is swallowed by it and the resolver does not see it.

So, maybe we need a test to ensure that the resolver does not see an update in this case? And that RPCs continue to succeed (if they were succeeding earlier)?

The test in the dependency manager is also mostly similar. Main difference would be the test in dependency managers uses the New function , and the test here will start with the resolver. Either way , adding it does no harm , so re- added.

easwars · 2025-11-17T23:07:48Z

internal/xds/clients/xdsclient/clientimpl_watchers.go

+		c.serializer.TrySchedule(func(context.Context) {
+			watcher.ResourceError(fmt.Errorf("ResourceType implementation for resource type url %v is not found", rType.TypeURL), func() {})
+		})


Are you fixing a bug in the existing code here? If so, did you get a chance to check the PR where this was added to see if there was in fact a reason for calling the watch callback outside of the serializer here?

Also, while you are here, it might be worth updating the docstring of this method and the ResourceWatcher interface (there is no mention of the serialization guarantees that are provided by the xDS client when calling methods on this interface). It says the watch will fail if the resource type implementation does not exist. But what does failing a watch mean? Also, it does not say anything about the case where the authority in the resource name is not found in the configuration (also, it should not say bootstrpa, as this is the generic xDS client, and bootstrap is a gRPC xDS client concept). You could even do it as a separate PR (both the bug fix and the fixes to the docstring).

easwars · 2025-11-17T23:19:56Z

internal/xds/resolver/xds_resolver.go

-	// All methods on the xdsResolver type except for the ones invoked by gRPC,
-	// i.e ResolveNow() and Close(), are guaranteed to execute in the context of
-	// this serializer's callback. And since the serializer guarantees mutual
-	// exclusion among these callbacks, we can get by without any mutexes to
-	// access all of the below defined state. The only exception is Close(),
-	// which does access some of this shared state, but it does so after
-	// cancelling the context passed to the serializer.


Without this comment, there is no comment about which fields' access need to be synchronized and which ares are set up at creation time and are read-only after that (and therefore don't need any synchronization).

Sorry , got deleted by mistake. Added again.

easwars · 2025-11-17T23:26:54Z

internal/xds/resolver/xds_resolver.go

+//   - prunes active clusters and pushes a new service config to the channel.
+//   - updates the current config selector used by the resolver.
+func (r *xdsResolver) Update(config *xdsresource.XDSConfig) {
+	r.serializer.TrySchedule(func(context.Context) {


Is there any need for this to be run in a blocking fashion?

Yes , because of the shared state of r.curConfigSelecteor

easwars · 2025-11-17T23:29:03Z

internal/xds/resolver/xds_resolver.go

-	// access all of the below defined state. The only exception is Close(),
-	// which does access some of this shared state, but it does so after
-	// cancelling the context passed to the serializer.
 	serializer       *grpcsync.CallbackSerializer


I guess we also discussed the possibility of reverting to using a mutex here as well instead of a serializer? Did you decide against doing it? Or did you do it and things didn't work?

Right , I did try that , but it did not work mainly becuase of the sendNewServiceConfig function , which can we called from multiple RPCs

eshitachandwani · 2025-11-18T13:07:21Z

Is the PR description out of date? I don't see any changes about switching the dependency manager to use the serializer again.

Yeah sorry , I was making that change earlier but Arjan suggested a different way, so that got changed.

change xds_resolver to use dependency manager

b866b9c

eshitachandwani added Type: Internal Cleanup Refactors, etc Area: xDS Includes everything xDS related, including LB policies used with xDS. labels Nov 17, 2025

eshitachandwani added this to the 1.78 Release milestone Nov 17, 2025

eshitachandwani requested review from arjan-bal and easwars and removed request for easwars November 17, 2025 03:27

eshitachandwani assigned easwars and arjan-bal Nov 17, 2025

arjan-bal reviewed Nov 17, 2025

View reviewed changes

arjan-bal assigned eshitachandwani and unassigned arjan-bal Nov 17, 2025

eshitachandwani changed the title ~~internal:xds change xds_resolver to use dependency manager~~ internal/xds: change xds_resolver to use dependency manager Nov 17, 2025

callbackserializer

84a9733

eshitachandwani requested a review from arjan-bal November 17, 2025 10:10

eshitachandwani assigned arjan-bal and unassigned eshitachandwani Nov 17, 2025

easwars reviewed Nov 17, 2025

View reviewed changes

easwars assigned eshitachandwani and unassigned easwars and arjan-bal Nov 17, 2025

eshitachandwani added 3 commits November 20, 2025 12:22

changes

a27125f

Merge remote-tracking branch 'upstream/master' into final_xds_resolver

0719ab0

add s to the test

3f87474

internal/xds: change xds_resolver to use dependency manager #8711

Are you sure you want to change the base?

internal/xds: change xds_resolver to use dependency manager #8711

Conversation

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

Uh oh!

Uh oh!

codecov bot commented Nov 17, 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!

easwars commented Nov 17, 2025

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!

eshitachandwani commented Nov 18, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

eshitachandwani commented Nov 17, 2025 •

edited

Loading

codecov bot commented Nov 17, 2025 •

edited

Loading