Skip to content

xds/xdsclient: create LRSClient at time of initialisation #8483

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

eshitachandwani
Copy link
Member

Fixes: #8474

The race is in ReportLoad function of clientImpl. The implementation was recently changed as the part of xds client migration.

The comment says that lrsclient.LRSClient should be initialized only at creation time but that was not the case. It was being initialized at the time of calling ReportLoad function.

RELEASE NOTES: N/A

@eshitachandwani eshitachandwani added this to the 1.75 Release milestone Aug 1, 2025
@eshitachandwani eshitachandwani added Type: Bug Area: xDS Includes everything xDS related, including LB policies used with xDS. labels Aug 1, 2025
Copy link

codecov bot commented Aug 1, 2025

Codecov Report

❌ Patch coverage is 80.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.46%. Comparing base (9186ebd) to head (90bc53c).
⚠️ Report is 6 commits behind head on master.

Files with missing lines Patch % Lines
xds/internal/xdsclient/clientimpl.go 80.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #8483      +/-   ##
==========================================
- Coverage   82.47%   82.46%   -0.02%     
==========================================
  Files         413      413              
  Lines       40513    40537      +24     
==========================================
+ Hits        33415    33429      +14     
- Misses       5743     5748       +5     
- Partials     1355     1360       +5     
Files with missing lines Coverage Δ
xds/internal/xdsclient/clientimpl_loadreport.go 76.92% <ø> (+4.19%) ⬆️
xds/internal/xdsclient/clientimpl.go 82.05% <80.00%> (-0.48%) ⬇️

... and 18 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

for i := 0; i < numGoroutines; i++ {
go func() {
store, cancelStore := client.ReportLoad(serverConfig)
if store != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this check? Why is the store nil?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can return nil in case of error, but in that case the cancelStore function will be a no-op function , so we can skip this check.

Copy link
Contributor

@arjan-bal arjan-bal Aug 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we expect an error to be returned in the test? If not, we should error log it to fail the test. My concern is that the current check may hide failures.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right! Got your point. It will return nil in case that the XDSClient does not have lrsclient field set. So I think it makes sense to log an error if it is not set , because we want to set it unconditionally at time of creation. Does that sound good?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look at the code again and I feel that we should get rid of the nil check entirely. We set the field at object creation time, so it should be impossible for it to be nil.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it! Done.

for i := 0; i < numGoroutines; i++ {
go func() {
store, cancelStore := client.ReportLoad(serverConfig)
if store != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had a look at the code again and I feel that we should get rid of the nil check entirely. We set the field at object creation time, so it should be impossible for it to be nil.

@arjan-bal arjan-bal modified the milestones: 1.75 Release, 1.74 Release Aug 1, 2025
@eshitachandwani eshitachandwani changed the title create lrs at creation time xds/xdsclient: create LRSClient at time of initialisation Aug 1, 2025
TransportBuilder: gConfig.TransportBuilder,
})
if err != nil {
return nil, err
Copy link
Contributor

@purnesh42H purnesh42H Aug 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have moved it out of report load, we might have think a bit more here. Should error in lrs client creation be fatal? because not everyone is going to use internal xdsclient for load reporting.

Copy link
Contributor

@arjan-bal arjan-bal Aug 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, we should keep the same behaviour as before the xDS client migration changes. If there are certain users who need to ignore LRS client creation failures, we can create a new issue to discuss if the bahviour changes makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to retain the behavior of making LRS client creation failures be fatal. But we might want to change one minor thing in lrsclient.New. Currently it fails if node ID is empty in the configuration. We recently removed that check for the xDS client creation. I'm guessing other languages might not treat this as fatal for LRS creation.

@eshitachandwani : Could you please check what the other languages do and if required remove the check for empty node ID in lrsclient.New. Thanks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly , Java is checking for not null here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That check is for the whole node proto or struct. Not just the node ID field.

TransportBuilder: gConfig.TransportBuilder,
})
if err != nil {
return nil, err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to retain the behavior of making LRS client creation failures be fatal. But we might want to change one minor thing in lrsclient.New. Currently it fails if node ID is empty in the configuration. We recently removed that check for the xDS client creation. I'm guessing other languages might not treat this as fatal for LRS creation.

@eshitachandwani : Could you please check what the other languages do and if required remove the check for empty node ID in lrsclient.New. Thanks.

for i := 0; i < numGoroutines; i++ {
go func() {
defer wg.Done()
_, cancelStore := client.ReportLoad(serverConfig)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to have a loop here as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure if I understand, loop for what?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A loop inside the goroutine to start reporting load and subsequently canceling it. What I'm asking for is:

	for i := 0; i < numGoroutines; i++ {
		go func() {
			defer wg.Done()
			for j := 0; j < 100; j++ {
				_, cancelStore := client.ReportLoad(serverConfig)
				cancelStore(ctx)
			}
		}()
	}

@easwars easwars assigned eshitachandwani and unassigned easwars and arjan-bal Aug 4, 2025
@eshitachandwani eshitachandwani requested a review from easwars August 5, 2025 12:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: xDS Includes everything xDS related, including LB policies used with xDS. Type: Bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Race condition in xds package
4 participants