xds: migrate internal xdsclient to use generic client and dedicated LRS client by purnesh42H · Pull Request #8310 · grpc/grpc-go

purnesh42H · 2025-05-12T09:11:42Z

This PR refactors the internal xdsclient package to leverage a shared, generic xDS client implementation and a dedicated LRS client for load reporting.

Generic Resource Watching: The core logic for watching xDS resources (like Listeners, Routes, Clusters, and Endpoints) is now handled by a generic xDS client library. Wrappers for generic xdsclient are added for existing internal resource types and watchers (xdsresource.Type, xdsresource.ResourceWatcher, etc.) to ensure transparency and minimal impact on current users of the internal xdsclient package.
Dedicated Load Reporting: Load reporting functionality was extracted into a new, dedicated LRS client (lrsclient). The ReportLoad method in the internal xdsclient now delegates to this new client, separating load reporting concerns from the main ADS client logic.
Test Suite Simplification: Redundant tests related to resource watching within the internal xdsclient package are removed, as this functionality is now covered by tests for the generic client.
Load Store Structure: The LoadStore implementation for aggregating load data continues to use the clients.Locality struct as keys for tracking locality-specific statistics. (Note: Dropped call counts are reported per category, which is represented by a string).

RELEASE NOTES: None

codecov · 2025-05-12T10:10:39Z

Codecov Report

Attention: Patch coverage is 81.79012% with 59 lines in your changes missing coverage. Please review.

Project coverage is 82.44%. Comparing base (f6bf86c) to head (6a472fb).
Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
...ds/internal/xdsclient/xdsresource/resource_type.go	58.00%	15 Missing and 6 partials ⚠️
xds/internal/xdsclient/clientimpl.go	88.79%	7 Missing and 6 partials ⚠️
xds/internal/xdsclient/pool.go	81.25%	4 Missing and 2 partials ⚠️
...nal/clients/xdsclient/internal/xdsresource/type.go	54.54%	5 Missing ⚠️
xds/internal/xdsclient/clientimpl_loadreport.go	76.19%	4 Missing and 1 partial ⚠️
xds/internal/clients/xdsclient/channel.go	57.14%	2 Missing and 1 partial ⚠️
xds/internal/internal.go	66.66%	3 Missing ⚠️
.../internal/balancer/loadstore/load_store_wrapper.go	84.61%	2 Missing ⚠️
xds/internal/testutils/fakeclient/client.go	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8310      +/-   ##
==========================================
+ Coverage   82.34%   82.44%   +0.10%     
==========================================
  Files         419      413       -6     
  Lines       42068    40450    -1618     
==========================================
- Hits        34639    33349    -1290     
+ Misses       5973     5744     -229     
+ Partials     1456     1357      -99

Files with missing lines	Coverage Δ
internal/xds/bootstrap/bootstrap.go	`65.35% <100.00%> (-0.38%)`	⬇️
xds/internal/balancer/clusterimpl/clusterimpl.go	`90.24% <100.00%> (+0.24%)`	⬆️
xds/internal/balancer/clusterimpl/picker.go	`100.00% <100.00%> (ø)`
...internal/balancer/clusterresolver/configbuilder.go	`92.85% <100.00%> (ø)`
...alancer/clusterresolver/configbuilder_childname.go	`100.00% <100.00%> (ø)`
xds/internal/balancer/wrrlocality/balancer.go	`68.81% <100.00%> (ø)`
xds/internal/clients/lrsclient/load_store.go	`93.19% <100.00%> (ø)`
xds/internal/clients/lrsclient/lrs_stream.go	`68.50% <100.00%> (+5.15%)`	⬆️
xds/internal/xdsclient/client.go	`100.00% <ø> (ø)`
xds/internal/xdsclient/clientimpl_watchers.go	`100.00% <100.00%> (+11.39%)`	⬆️
... and 14 more

... and 24 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-05-12T22:33:47Z

xds/internal/xdsclient/clientimpl_loadreport.go

-		releaseChannelRef()
-	}
+	return load, sync.OnceFunc(func() {
+		ctx, cancel := context.WithTimeout(context.Background(), loadStoreStopTimeout)


It looks like this operation did not block before this change. We should plumb the context back as far as we can if we are going to use a context. I.e. the function returned would be func(context.Context).

Also the implementation of load.Stop seems to block indefinitely on a channel closing, even if the context was cancelled. That looks wrong, because if there is a context, it should respect it. I think this needs to be looked at a bit more closely. Maybe it's as simple as changing the context into a timeout (time.Duration) to apply to the final stream write?

It looks like this operation did not block before this change. We should plumb the context back as far as we can if we are going to use a context. I.e. the function returned would be func(context.Context).

Modified to accept context.Context. I checked google3 and didn't find any usage of ReportLoad outside of grpc so changing the function signature is fine here.

Also the implementation of load.Stop seems to block indefinitely on a channel closing, even if the context was cancelled.

are you referring to <-lrs.doneCh here https://github.com/grpc/grpc-go/blob/master/xds/internal/clients/lrsclient/lrsclient.go#L172? because the above final send has a select block that respect the provided ctx

I'll have to look and see how this plumbs back, but I'm skeptical we already have a context where we need it. Remember that only Main/server handlers should be creating contexts from Background, and there are checkers that could get in our way of doing otherwise.

we are not creating the stop context in lrs client. Its provided by user.

For grpc case, the LoadStore.Stop() is called by clusterimpl in updateLoadStore method in xds/internal/balancer/clusterimpl/clusterimpl.go. The updateLoadStore method is called from the UpdateClientConnState method of the clusterImplBalancer. The UpdateClientConnState method is called when a new cluster update from xds management server is received. The UpdateClientConnState method itself does not receive a context.Context. There isn't a natural parent context available that is specifically tied to the lifecycle of this configuration update.

The stopCtx created with context.WithTimeout(context.Background(), loadStoreStopTimeout) is specifically used to provide a deadline for the b.cancelLoadReport function. This function, in turn, wraps the Stop method of the lrsclient.LoadStore. The LoadStore.Stop method takes a context. b.CancelLoadReport is called in Close() method of clusterImplBalancer and within updateLoadStore if stopOldLoadReport is true. I think its fine for Close() to block on stopping the loadstore? May be for the other case we can do in a new goroutine if we don't want to block.

The UpdateClientConnState method itself does not receive a context.Context. There isn't a natural parent context available that is specifically tied to the lifecycle of this configuration update.

Right, which is why I'm saying we probably don't want to use a context here, because we can't create one without triggering some checkers that I'd rather just avoid. https://google.github.io/styleguide/go/decisions#contexts

yeah, so we can create a timer from passed timeout and put that in the select block like below in stop function. Is that reasonable?

timer := time.NewTimer(timeout) defer timer.Stop() select { case err := <-lrs.finalSendDone: if err != nil { c.logger.Warningf("Final send attempt failed: %v", err) } case <-timer.C: // The operation to send the final load report and get confirmation // via finalSendDone did not complete within the timeout. c.logger.Warningf("Final send attempt timed out after %v", timeout }

Unfortunately, I don't think there's any other choice if we can't create a context and don't already have one.

I have updated to use time.Duration for LoadStore.Stop()

dfawley · 2025-05-12T22:47:37Z

xds/internal/balancer/clusterimpl/balancer_test.go

-	}}
-
-	gotStatsData0 := loadStore.Stats([]string{testClusterName})
-	if diff := cmp.Diff(gotStatsData0, wantStatsData0, cmpOpts); diff != "" {


Why are these tests removed? Are we testing all the stats (sufficiently) elsewhere?

the external client has tests specifically for testing all stats scenarios. We haven't exported the stats function so we can't compare stats exactly like this anymore here.

The other e2e test tests/balancer_test does verify the stats through a fake server which allows intercepting the received report request.

Are we covering all the same metrics? Can we add an LRS implementation that can aggregate the reports and provide them in a similar way?

If we are deleting this, then loadStore is now unused.

I think implementing entire LRS implementation is not possible because lrsclient PerClusterReporter is not an interface that we can implement for grpc tests.

One thing is possible though with what we have currently. The picker in clusterImpl has a wrapper for loadStore of type loadReporter which is an interface https://github.com/purnesh42H/grpc-go/blob/generic-xds-client-migrate-internal-e2e/xds/internal/balancer/clusterimpl/picker.go#L86. ClusterImpl sets this field to a wrapper that uses lrsclient.LoadStore to report stats.

We can override the picker's loadStore in our tests with the test loadReporter that allows us to count and fetch stats but the underneath lrsclient.LoadStore is unused then which might be fine because for this test we want to verify the picker's logic only. Let me know if that sounds good to you.

Let me know if something like this is okay 7da08b1

@dfawley. In case it wasn't missed

Ok. So, I made a couple of comments about this above, but after reading this thread, I have some more context.

The issue is that the the ReportLoad method on the xDS client returns a struct, and the load store only exposes method to report load data, but not to verify the reported load data. So, this approach of using a test double for the load store seems Ok for the time being. But, maybe we should have a TODO here to find other means to test this and avoid so much test-util code.

Thanks. I have filed a sub-issue #8366

dfawley · 2025-05-12T22:50:22Z

xds/internal/xdsclient/clientimpl.go

+func init() {
+	DefaultPool = &Pool{clients: make(map[string]*clientRefCounted)}
 }


You shouldn't need an init for this - just iniitalize DefaultPool inline.

dfawley · 2025-05-12T22:52:32Z

xds/internal/xdsclient/clientimpl.go

+				}
+				bundle, _, err := c.Build(cc.Config)
+				if err != nil {
+					continue


This doesn't feel like a continue to me. If we failed to build, that seems like a pretty big error that we should at least log, if not return.

yes, my mistake. I checked the internal xds/bootstrap.go logic and we do return error if we failed to build creds. Changed to return error.

dfawley · 2025-05-12T22:55:29Z

xds/internal/xdsclient/clientimpl.go

+				continue
+			}
+			bundle, _, err := c.Build(cc.Config)
+			if err != nil {


As above. This looks like duplicate code. Can you refactor?

Refactored into helper.

dfawley · 2025-05-19T20:01:18Z

xds/internal/balancer/clusterimpl/balancer_test.go

-	}}
-
-	gotStatsData0 := loadStore.Stats([]string{testClusterName})
-	if diff := cmp.Diff(gotStatsData0, wantStatsData0, cmpOpts); diff != "" {


Are we covering all the same metrics? Can we add an LRS implementation that can aggregate the reports and provide them in a similar way?

If we are deleting this, then loadStore is now unused.

dfawley · 2025-05-19T20:01:40Z

xds/internal/balancer/clusterimpl/clusterimpl.go

 	xdsClient        xdsclient.XDSClient     // Sent down in ResolverState attributes.
-	cancelLoadReport func()                  // To stop reporting load through the above xDS client.
+	cancelLoadReport func(time.Duration)     // To stop reporting load through the above xDS client.
 	edsServiceName   string                  // EDS service name to report load for.


This still has a context?

it accepts timeout value now to cancel the load report. cancelLoadReport calls Stop on underlying LoadStore with same timeout. There is no context anymore here.

Let's follow along with the question to the Go team. It could be that using a context.TODO at our callsite is acceptable. Ideally the API would accept a context, because that matches http.Server.Shutdown, and it feels like a very similar usage pattern. :(

So, based on their last reply we can create the context from context.TODO in clusterimpl. We need to file an exception though but it might not be very difficult to get exception since no callsites are exported to user. Did i get it right?

Let's go back to the context, I suppose, since I recently discovered http.Server.Shutdown, which also uses context for essentially the same thing. We will deal with an exception if we need one. I suspect we won't, because those things don't end up using xds anyway. For now.

Switched back to using context. One more thing. From the other bug related to LRS reporting interval b/416260484, it looks like max report interval can be upto 10 seconds. Do you think we should use 10s in clusterimpl for timeout in loadStore.Stop()?

I'm not sure of the semantics here. Is it illegal to report before the interval expires, or can we do one early report at any time before closing the stream? If we can't send it early, then is it important to capture the partial load report at the end of connections?

I followed c-core implementation. They don't have any notion of early report. Final statistics are aggregated and queued and sent with the next regular report. So, essentially they are waiting until the next reporting cycle. Although they do have a minimum load report interval 1s which is used if actual load reporting interval is lower than 1s but that's applicable overall not just to final report.

In our case as well, after calling Stop() if refs become 0, we notify the lrs stream runner about final report so when it comes back on next time, it reports the final stats and then cancel the stream. The only difference here is we are taking the deadline from user to not block indefinitely (in case of some internal error). For grpc, its probably good if we set this value to the max possible from TD because at the grpc level we don't have access to reporting interval from lrs server.

One more thing i realized is we don't cancel/nullify the PerClusterReporter so technically more loads can be added to it even after calling stop. Should we document that after calling Stop on LoadStore, any operation on PerClusterReporter is undefined?

xds/internal/balancer/loadstore/load_store_wrapper.go

xds/internal/testutils/fakeclient/client.go

xds/internal/xdsclient/xdsresource/resource_type.go

dfawley · 2025-05-20T21:00:40Z

xds/internal/xdsclient/xdsresource/resource_type.go

+	return rawAny.Value
+}
+
+// genericResourceWatcher embed ResourceWatcher and implements


Same re: embedded.

But.. can we delete ResourceWatcher instead of implementing it? The idea is that we moved the definition over to the clients/xdsclient package.

Changed to wrap

can we delete ResourceWatcher instead of implementing it? The idea is that we moved the definition over to the clients/xdsclient package.

I looked at the google3 usages and WatchResource API is being used in different resolvers. So, if we remove the wrapper then the change won't be transparent due to ResourceType being different and after import we will need manual changes.

On that note, what is the eventual goal? Will we move the other resolvers to directly use generic xdsclient? If yes, then we can just remove some of these wrappers after switching them.

@dfawley in case it was missed

xds/internal/xdsclient/clientimpl.go

dfawley · 2025-05-20T21:09:09Z

xds/internal/xdsclient/clientimpl.go


+func newClientImplGeneric(config *bootstrap.Config, metricsRecorder estats.MetricsRecorder, resourceTypes map[string]gxdsclient.ResourceType, target string) (*clientImpl, error) {
+	grpcTransportConfigs := make(map[string]grpctransport.Config)
+	gServerCfgMap := make(map[gxdsclient.ServerConfig]*bootstrap.ServerConfig)


Why are we making this map? What data are we needing to get from of our grpc server config that isn't in the generic server config, or can't be put into the generic ServerIdentifier as an extension?

Technically, we need a single ServerConfig while decoding but because we need to provide all resource types at the time of creating client, we need to initialize it with all ServerConfigs and then fetch the required bootstrap.ServerConfig one based on the generic xdsclient.ServerConfig from DecodeOptions within decoder. The internal xdsclient lazily adds resource type when it starts watching so it has the needed ServerConfig at the time of registering the type. Hence, it doesn't need the map.

I explained the reason for map in above comment.

What data are we needing to get from of our grpc server config that isn't in the generic server config

cds resource parsing needs the server config for the LRS server https://github.com/grpc/grpc-go/blob/master/xds/internal/xdsclient/xdsresource/unmarshal_cds.go#L199.

@dfawley in case it was missed

dfawley

Have you tested this internally by doing an import from your branch? If you haven't already, can you please coordinate with @danielzhaotongliu so you can run their tests as well, as we discussed previously.

xds/internal/balancer/clusterimpl/clusterimpl.go

dfawley · 2025-05-23T17:55:00Z

xds/internal/balancer/clusterimpl/clusterimpl.go

 		addr := connectedAddress(state)
 		lID := xdsinternal.GetLocalityID(addr)
-		if lID.Empty() {
+		if xdsinternal.IsLocalityEmpty(lID) {


Maybe delete the function and directly use lID == clients.LocalityID{}?

purnesh42H · 2025-05-26T08:45:23Z

Have you tested this internally by doing an import from your branch? If you haven't already, can you please coordinate with @danielzhaotongliu so you can run their tests as well, as we discussed previously.

I have imported it in google3 cl/763291147 and it was successful without any manual changes. I ran all the prod resolver tests as well and they ran fine. I have asked @danielzhaotongliu to run their local tests as well.

I was waiting to import for few review iterations till we are good correctness wise and won't be doing major changes. Is it looking close enough?

dfawley · 2025-05-27T18:33:48Z

xds/internal/clients/grpctransport/grpc_transport_test.go

 // testDiscoverResponse from the server and verifies that the received
 // discovery response is same as sent from the server.
-func (s) TestStream_SendAndRecv(t *testing.T) {
+func TestStream_SendAndRecv(t *testing.T) {


Why is this changed?

By mistake. Reverted

dfawley · 2025-06-04T20:58:56Z

@purnesh42H can you please remove the dependency on the codes proto? We use grpc/codes instead. It looks like on master, ads_stream.go references it.

purnesh42H · 2025-06-05T04:34:32Z

@purnesh42H can you please remove the dependency on the codes proto? We use grpc/codes instead. It looks like on master, ads_stream.go references it.

Shouldn't we not be using grpc packages for this? For now, I have made into a local constant. Let me know if that's ok.

dfawley · 2025-06-05T15:35:27Z

Shouldn't we not be using grpc packages for this? For now, I have made into a local constant. Let me know if that's ok.

Hmm, yes you are correct. This is a little unfortunate. It looks like C++ uses ABSL to create this invalid argument error, and Java uses the codes proto. So I think you can revert this commit. The proto in question is very small, and we already use the same module for the status proto, so I don't think this should be significant.

This reverts commit 8b6d364.

purnesh42H · 2025-06-06T05:36:59Z

Shouldn't we not be using grpc packages for this? For now, I have made into a local constant. Let me know if that's ok.

Hmm, yes you are correct. This is a little unfortunate. It looks like C++ uses ABSL to create this invalid argument error, and Java uses the codes proto. So I think you can revert this commit. The proto in question is very small, and we already use the same module for the status proto, so I don't think this should be significant.

Reverted

…icated LRS client (grpc#8310)" This reverts commit 996aabe.

…edicated LRS client This reverts commit 996aabe.

…client and dedicated LRS client" This reverts commit d2e8366.

…nd dedicated LRS client This reverts commit 996aabe.

purnesh42H added Area: xDS Includes everything xDS related, including LB policies used with xDS. Type: Feature New features or improvements in behavior labels May 12, 2025

purnesh42H added this to the 1.73 Release milestone May 12, 2025

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 4a25c97 to aa38b33 Compare May 12, 2025 09:22

purnesh42H changed the title ~~xds: migrate internal xdsclient to use generic xds client~~ xds: migrate internal xdsclient to use generic client and dedicated LRS client May 12, 2025

purnesh42H requested review from dfawley and easwars May 12, 2025 14:04

purnesh42H assigned dfawley and easwars May 12, 2025

This was referenced May 12, 2025

xds: generic xds client ads stream tests #8307

Merged

xds: Introduce new generic xDS and LRS clients decoupled from gRPC-specific elements and migrate internal xDS and LRS functionality to use new generic clients #8313

Closed

dfawley reviewed May 14, 2025

View reviewed changes

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 7302202 to a1f489d Compare May 15, 2025 20:13

purnesh42H requested a review from dfawley May 15, 2025 21:17

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 3127e3f to 038ea2b Compare May 19, 2025 18:40

dfawley reviewed May 20, 2025

View reviewed changes

dfawley assigned purnesh42H and unassigned easwars and dfawley May 20, 2025

purnesh42H requested a review from dfawley May 21, 2025 15:42

purnesh42H assigned dfawley and easwars and unassigned purnesh42H May 21, 2025

dfawley reviewed May 23, 2025

View reviewed changes

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 00d6aa4 to c0a8c38 Compare May 26, 2025 06:00

purnesh42H requested a review from dfawley May 26, 2025 14:32

purnesh42H mentioned this pull request May 27, 2025

xdsclient: race around resource subscriptions and unsubscsriptions #8125

Closed

dfawley reviewed May 27, 2025

View reviewed changes

purnesh42H added 8 commits June 5, 2025 01:52

rewrite balancer_test in clusterimpl with testLoadReporter

d000ae0

revert back loadStore.Stop() to accept context

2cf0d5d

dfawley review 2

6e94b97

add back internal client related cleanup operations

be0d4d3

revert local copy in updateLocalityID

a6a28f2

easwars review 1

80c522f

mend

c48b56e

easwar review 2

5fa58f0

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 0e0fb60 to 5fa58f0 Compare June 4, 2025 20:25

purnesh42H mentioned this pull request Jun 4, 2025

xds/internal: Remove wrappers and embeddings from grpc xdsclient and re-write resource types and watchers as per generic client interfaces #8381

Closed

purnesh42H added 2 commits June 5, 2025 02:57

add TODO(s)

5b28fc4

remove code proto

8b6d364

eshitachandwani modified the milestones: 1.73 Release, 1.74 Release Jun 5, 2025

purnesh42H added 2 commits June 5, 2025 23:00

Revert "remove code proto"

1ae69e0

This reverts commit 8b6d364.

remaining

6a472fb

purnesh42H force-pushed the generic-xds-client-migrate-internal-e2e branch from 3ce4064 to 6a472fb Compare June 5, 2025 18:07

purnesh42H merged commit 996aabe into grpc:master Jun 6, 2025
22 of 35 checks passed

arjan-bal added a commit to arjan-bal/grpc-go that referenced this pull request Jun 9, 2025

Revert "xds: migrate internal xdsclient to use generic client and ded…

5944a42

…icated LRS client (grpc#8310)" This reverts commit 996aabe.

arjan-bal mentioned this pull request Jun 9, 2025

xds: revert #8310: migration of xdsclient to use generic client and dedicated LRS client #8387

Merged

arjan-bal added a commit that referenced this pull request Jun 9, 2025

xds: revert #8310: migration of xdsclient to use generic client and d…

d2e8366

…edicated LRS client This reverts commit 996aabe.

purnesh42H added a commit to purnesh42H/grpc-go that referenced this pull request Jun 10, 2025

Revert "xds: revert grpc#8310: migration of xdsclient to use generic …

b33c93d

…client and dedicated LRS client" This reverts commit d2e8366.

purnesh42H mentioned this pull request Jun 12, 2025

Rollforward xdsclient migrate internal #8391

Merged

vinothkumarr227 pushed a commit to vinothkumarr227/grpc-go that referenced this pull request Jun 19, 2025

xds: revert grpc#8310: migration of xdsclient to use generic client a…

e30ae1c

…nd dedicated LRS client This reverts commit 996aabe.

yashuatla mentioned this pull request Jun 25, 2025

Feature implementation from commits 28128e0..d2e8366 yashuatla/grpc-go#1

Open

github-actions bot locked as resolved and limited conversation to collaborators Dec 4, 2025

Conversation

purnesh42H commented May 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented May 12, 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!

purnesh42H May 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

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!

purnesh42H May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

purnesh42H commented May 12, 2025 •

edited

Loading

codecov bot commented May 12, 2025 •

edited

Loading

purnesh42H May 19, 2025 •

edited

Loading

purnesh42H May 26, 2025 •

edited

Loading

purnesh42H May 21, 2025 •

edited

Loading

purnesh42H May 21, 2025 •

edited

Loading

purnesh42H commented May 26, 2025 •

edited

Loading