feat: revert #3400: reintroduce experimental S2A integration in client libraries grpc transport #3548

rmehta19 · 2025-01-07T01:27:24Z

Revert #3400.

This PR re-introduces the S2A integration the Java Cloud SDK (initially introduced in #3326, and temporarily reverted in #3400).

This PR does this by reverting #3400 with the following patches:

load the S2A APIs via reflection. This allows us to merge the code while the S2A API is still experimental in gRPC-Java without introducing a diamond dependency conflict. Once the S2A APIs are stable, the reflection logic can be removed and the S2A API can be used directly (via a dependency on S2A API)
fix NPE (s2a fix: fix NPE. #3401)
use a different env var name for enabling the feature

Below is the original description from #3326

Modify the Client Libraries gRPC Channel builder to use mTLS via S2A if the experimental environment variable is set, S2A is available (We check this by using SecureSessionAgent utility), and a few more conditions (see shouldUseS2A).

Following https://google.aip.dev/auth/4115, Only attempt to use S2A after DirectPath and DCA (https://google.aip.dev/auth/4114) are ruled out as options. If conditions to use S2A are not met (env variable not set, or S2A is not running in environment, etc (shouldUseS2A returns false)), fall back to default TLS connection.

When we are creating S2A-enabled Grpc Channel Credentials, we first try to secure the connection between the client and the S2A via MTLS, using MTLS-MDS credentials. If MTLS-MDS credentials can't be loaded, then we fallback to a plaintext connection between the client and S2A.

The parallel go implementation : googleapis/google-api-go-client#1874 (now lives here: https://github.com/googleapis/google-cloud-go/blob/main/auth/internal/transport/cba.go)

S2A Java client: https://github.com/grpc/grpc-java/tree/master/s2a

Resolving b/376258193 means that S2A.java is no longer experimental

rmehta19 · 2025-01-07T15:00:08Z

.../google/api/generator/gapic/composer/grpc/goldens/samples/bookshopclient/AsyncGetBook.golden

@@ -1,5 +1,5 @@
 /*
- * Copyright 2024 Google LLC


Looks like running mvn fmt:format resulted in all these changes. Perhaps these changes could be made in another PR and then can be removed from this PR.

Looks like these are missed in #3513.
We will do a separate PR for these and you can remove from this PR

Thanks! with the latest merge of main, these changes have been removed from this PR.

rmehta19 · 2025-01-07T15:13:29Z

@lqiu96 @blakeli0 @zhumin8 , please review, thanks!

xmenxk · 2025-01-10T17:12:12Z

gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java

+      String s2AEnv;
+      s2AEnv = envProvider().getenv(S2A_ENV_ENABLE_USE_S2A);


nit: this can be one line.

xmenxk · 2025-01-10T17:17:03Z

gax-java/gax/src/main/java/com/google/api/gax/rpc/EndpointContext.java

@@ -288,6 +306,37 @@ private String determineEndpoint() throws IOException {
      return endpoint;
    }

+    /** Determine if S2A can be used */
+    @VisibleForTesting
+    boolean shouldUseS2A() {


There was a issue raised re: netty-tcnative dropping support for Windows and MacOS Intel platforms, do we want to add the runtime checks here an skip S2A if the code is running on an unsupported platforms?

We can also do that in a followup PR, but just to mention it here so we don't forget.

Thanks for flagging this Kui, I think this is fine to get to in a followup PR. Sent you a ping with some details.

(We can probably use System.getProperty("os.name") to get this info. Precedence for doing so is in existing DirectPath logic: https://github.com/googleapis/sdk-platform-java/blob/main/gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java#L368)

xmenxk · 2025-01-10T17:28:34Z

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java

+        }
+        if (channelCredentials != null) {
+          // Create the channel using S2A-secured channel credentials.
+          builder = Grpc.newChannelBuilder(mtlsEndpoint, channelCredentials);


I assume this is what we discussed re: only pick the mtls endpoint when we know s2a will be used and directpath will not be used, but let know if otherwise. thanks

Yes this is correct. We removed the logic in determineEndpoint in EndpointContext to set the mtls endpoint if shouldUseS2A returns true. We instead plumb down the mtls endpoint so that we use it only when we know DirectPath is not being used.

This is because the decision to use S2A and the decision to use DirectPath happen in different places (EndpointContext vs InstantiatingGrpcChannelProvider).

lqiu96 · 2025-01-13T20:11:57Z

gax-java/gax/src/main/java/com/google/api/gax/rpc/TransportChannelProvider.java

+  /** True if the TransportProvider has no mtlsEndpoint set. */
+  boolean needsMtlsEndpoint();
+
  /**
   * Sets the endpoint to use when constructing a new {@link TransportChannel}.
   *
   * <p>This method should only be called if {@link #needsEndpoint()} returns true.
   */
  TransportChannelProvider withEndpoint(String endpoint);

+  /**
+   * Sets the mtlsEndpoint to use when constructing a new {@link TransportChannel}.
+   *
+   * <p>This method should only be called if {@link #needsMtlsEndpoint()} returns true.
+   */
+  TransportChannelProvider withMtlsEndpoint(String mtlsEndpoint);


Let me think about this a bit more. I'm not the biggest fan of adding these two public methods in needsMtlsEndpoint + withMtlsEndpoint and would prefer not to if possible.

I know this is a limitation regarding DirectPath and how that's determined. If we can't find a reasonable alternative, then I think I'm fine with this.

Took a look at this and I think there are possible a few alternatives to what is in this PR. Not sure entirely what all the pros and cons are as of now, but just going to pose them as possibilities.

Remove the .mtls substring when using directpath flow. This is probably the simplest option, but is pretty much a workaround. Given that S2A may end up being used much more, I don't think I would like endpoint resolution to be based on string find and replace.

Create a default method canUseDirectPath() in the TransportChannelProvider interface

default boolean canUseDirectPath() { return false; }

I believe this allows us to use it via the ClientContext to resolve the endpoint before we create the TransportChannel:
i.e.

if (transportChannelProvider.needsEndpoint()) { if (transportChannelProvider.canUseDirectPath()) { transportChannelProvider = transportChannelProvider.withEndpoint(endpointContext.mtlsEndpoint()); } else { transportChannelProvider = transportChannelProvider.withEndpoint(endpoint); } }

It shouldn't affect users who manually create InstantiatingGrpcChannelProvider since the logic still resides in there and is used during channel creation.

Let me talk with the team and see if there are any other potential concerns that I'm missing with this. I think option 2 might be a possibility and if not, then I think we can proceed with this.

Thanks for looking into this Lawrence.

Remove the .mtls substring when using directpath flow. This is probably the simplest option, but is pretty much a workaround. Given that S2A may end up being used much more, I don't think I would like endpoint resolution to be based on string find and replace.

Agreed that this is probably the simplest option. However I also am hesitant about modifying the endpoint using string find and replace, as you pointed out.

Create a default method canUseDirectPath() in the TransportChannelProvider interface

I think I understand this, however I think it might not be possible without reworking a few things with canUseDirectPath:

Looking at canUseDirectPath, it calls:

canUseDirectPathWithUniverseDomain, which relies on endpoint being set

isCredentialDirectPathCompatible, which relies on credential being set in ClientContext

The second one is easy to resolve, just be sure to call transportChannelProvider.needsCredentials() before transportChannelProvider.canUseDirectPath() in ClientContext. The first one will probably require moving that check out of canUseDirectPath and into ClientContext. I think this list is complete, but we may find more when we go to implement this.

Also, I think small typo in example you provided, should it be?:

if (transportChannelProvider.needsEndpoint()) { if (transportChannelProvider.canUseDirectPath()) { transportChannelProvider = transportChannelProvider.withEndpoint(endpoint); } else { transportChannelProvider = transportChannelProvider.withEndpoint(endpointContext.mtlsEndpoint()); } }

Also, perhaps we could change it to set the mtls endpoint only if shouldUseS2A and !canUseDirectPath, and use endpoint derived via endpointResolution in all other cases?

As discussed offline, we will not plumb the mtls endpoint for now, and just set the mtls endpoint if S2A can be used in EndpointContext in 25445d3

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java

lqiu96 · 2025-01-16T17:04:53Z

gax-java/gax/clirr-ignored-differences.xml

  </difference>
-  <!-- Ignore this as this was part of s2a-grpc ExperimentalApi revert -->
+  <!-- Ignore method addition to an TransportChannelProvider interface -->


Suggested change

Done in e921696

lqiu96 · 2025-01-16T17:05:02Z

gax-java/gax/clirr-ignored-differences.xml

@@ -106,16 +106,26 @@
    <className>com/google/api/gax/batching/Batcher</className>
    <method>*</method>
  </difference>
-  <!-- Ignore this as this was part of s2a-grpc ExperimentalApi revert -->
+  <!-- Ignore abstract method addition to an EndpointContext -->


nit: Adding the why (i.e. it's marked as internal)

Suggested change

Done in e921696

lqiu96 · 2025-01-16T18:41:17Z

/gcbrun

rmehta19 · 2025-01-21T18:42:14Z

@blakeli0 , @zhumin8 would you be able to review? Thanks!

blakeli0 · 2025-01-21T19:05:38Z

gax-java/gax/src/main/java/com/google/api/gax/rpc/TransportChannelProvider.java

+  @BetaApi(
+      "The S2A feature is not stable yet and may change in the future. https://github.com/grpc/grpc-java/issues/11533.")
+  default TransportChannelProvider withUseS2A(boolean useS2A) {
+    throw new UnsupportedOperationException("S2A is not supported");


I know we decided to throw exception last time we reviewed it, but we discovered that this could break downstream libraries' or customers' tests if they have a mock TransportChannelProvider. To prevent such breaking changes, can we change this to return this; instead? Then we don't have to override this method in other implementations (LocalChannelProvider, InstantiatingHttpJsonChannelProvider etc.) of this interface as well.

Thanks for bringing this up! Changed the default behavior to return this and removed overriding of the method in all other implementations except gRPC.

1703f51

blakeli0 · 2025-01-21T22:55:00Z

/gcbrun

rmehta19 · 2025-01-21T23:36:30Z

@blakeli0 I see there are 2 failing checks. Looking at the logs, the failures seem unrelated to the changes in this PR, WDYT?

zhumin8 · 2025-01-22T19:25:58Z

sonar check is not supported for forked branches. And you can ignore "Build with Airlock" check for now.

rmehta19 · 2025-01-22T20:33:28Z

@zhumin8 does this PR look ok to you? If so, are you able to merge (as I don't have write access)? Thank you!

blakeli0 · 2025-01-22T22:51:29Z

@rmehta19 Please resolve the conflict in InstantiatingGrpcChannelProvider, which is probably caused by #3467. We'll merge it once it is resolved.

rmehta19 · 2025-01-22T23:18:28Z

@rmehta19 Please resolve the conflict in InstantiatingGrpcChannelProvider, which is probably caused by #3467. We'll merge it once it is resolved.

Thanks @blakeli0, the conflict is resolved.

blakeli0 · 2025-01-22T23:19:07Z

/gcbrun

rmehta19 · 2025-01-22T23:43:18Z

I was looking through resolved comments and I found this one, I think mine and @lqiu96 's comments might have crossed at the same time..

I think the resolution is that we should be putting the

if (shouldUseS2A()) {
        return mtlsEndpoint();
      }

at the end of determineEndpoint() as "universe domain support with mtls may require this additional logic". Right now it's at the beginning. WDYT @lqiu96, @blakeli0?

I tested in an internal patch, having this at the beginning or end of determineEndpoint() works for our GCP use cases, and while S2A is experimental, shouldUseS2A() will anyways return false, so it won't impact customers (on or off GCP).

lqiu96 · 2025-01-23T21:24:48Z

I was looking through resolved comments and I found this one, I think mine and @lqiu96 's comments might have crossed at the same time..

I think the resolution is that we should be putting the
if (shouldUseS2A()) {
        return mtlsEndpoint();
      }
at the end of determineEndpoint() as "universe domain support with mtls may require this additional logic". Right now it's at the beginning. WDYT @lqiu96, @blakeli0?

I tested in an internal patch, having this at the beginning or end of determineEndpoint() works for our GCP use cases, and while S2A is experimental, shouldUseS2A() will anyways return false, so it won't impact customers (on or off GCP).

Took another look at this and I'm curious about the behavior regarding S2A and having the resolved endpoint be the non-mtls endpoint. mtlsResolver simply determines to use the mtls endpoint or the non-mtls endpoint. Based on the logic, I think it's possible that the resolved endpoint ends up being non-mtls endpoint, but S2A is true.

Should we guard against this or return an error? I think in this case, we may need to put this towards the end.

rmehta19 · 2025-01-23T21:44:32Z

I was looking through resolved comments and I found this one, I think mine and @lqiu96 's comments might have crossed at the same time..
I think the resolution is that we should be putting the
if (shouldUseS2A()) {
        return mtlsEndpoint();
      }
at the end of determineEndpoint() as "universe domain support with mtls may require this additional logic". Right now it's at the beginning. WDYT @lqiu96, @blakeli0?
I tested in an internal patch, having this at the beginning or end of determineEndpoint() works for our GCP use cases, and while S2A is experimental, shouldUseS2A() will anyways return false, so it won't impact customers (on or off GCP).
Took another look at this and I'm curious about the behavior regarding S2A and having the resolved endpoint be the non-mtls endpoint. mtlsResolver simply determines to use the mtls endpoint or the non-mtls endpoint. Based on the logic, I think it's possible that the resolved endpoint ends up being non-mtls endpoint, but S2A is true.

Should we guard against this or return an error? I think in this case, we may need to put this towards the end.

Thanks for looking @lqiu96. It would be an error to use S2A with a non-MTLS endpoint, because when we start using the MTLS_S2A hard bound tokens on the connection, the requests would get rejected. To be clear: if S2A is used, the resolved endpoint needs to be an MTLS endpoint.

Based on the logic, I think it's possible that the resolved endpoint ends up being non-mtls endpoint, but S2A is true.

I'm not sure I am following this. With this check in the beginning or end of determineEndpoint, if S2A(shouldUseS2A) is true, the resolved endpoint will be a MTLS endpoint. There is an early return however for GDCH, so I do think it makes sense to move the check to the end of determineEndpoint, because if GDCH is being used, a custom endpoint gets returned.

In 6f56cff I moved the check to the end of determineEndpoint.

lqiu96 · 2025-01-23T21:50:21Z

if S2A(shouldUseS2A) is true, the resolved endpoint will be a MTLS endpoint.

Oh sorry, what I wrote was confusing. What I meant is that it is possible that the mtlsResolver may return a non-mtls endpoint while shouldUseS2A is true (enabled). It would be confusing since mtlsResolver ends up checking the things that are required to enable MTLS (i.e. the required env vars and keystore, etc). So user may have set up for S2A, but the environment is accidentally configured to non-mtls. In this case, it would be that the environment can use non-mtls, but the user is set up for S2A (trying to mTLS), which seems to be a whole set of configuration issues/ mismatch. In this case, I think we would want to error out?

Hopefully that is clearer about what I was trying to point out.

rmehta19 · 2025-01-23T22:53:13Z

if S2A(shouldUseS2A) is true, the resolved endpoint will be a MTLS endpoint.

Oh sorry, what I wrote was confusing. What I meant is that it is possible that the mtlsResolver may return a non-mtls endpoint while shouldUseS2A is true (enabled). It would be confusing since mtlsResolver ends up checking the things that are required to enable MTLS (i.e. the required env vars and keystore, etc). So user may have set up for S2A, but the environment is accidentally configured to non-mtls. In this case, it would be that the environment can use non-mtls, but the user is set up for S2A (trying to mTLS), which seems to be a whole set of configuration issues/ mismatch. In this case, I think we would want to error out?

Hopefully that is clearer about what I was trying to point out.

Thanks for elaborating @lqiu96! I responded with detail on chat internally.

lqiu96 · 2025-01-24T00:14:43Z

Thanks for the explanation. The changes LGTM! Will merge after the Graalvm checks. Sonar and airlock CI issues can be ignored.

lqiu96 · 2025-01-24T00:15:01Z

/gcbrun

🤖 I have created a release *beep* *boop* --- <details><summary>2.52.0</summary> ## [2.52.0](v2.51.1...v2.52.0) (2025-01-24) ### Features * add support for new setAllowHardBoundTokens field. ([#3467](#3467)) ([38431a2](38431a2)) * revert [#3400](#3400): reintroduce experimental S2A integration in client libraries grpc transport ([#3548](#3548)) ([65a0f11](65a0f11)) ### Dependencies * update dependency com.google.api-client:google-api-client-bom to v2.7.2 ([#3578](#3578)) ([f6e5ad9](f6e5ad9)) * update dependency commons-codec:commons-codec to v1.17.2 ([#3557](#3557)) ([07ce801](07ce801)) * update dependency gitpython to v3.1.44 ([#3559](#3559)) ([e924db0](e924db0)) * update dependency org.checkerframework:checker-qual to v3.48.4 ([#3560](#3560)) ([a4726e9](a4726e9)) * update dependency smmap to v5.0.2 ([#3561](#3561)) ([6cd5d0d](6cd5d0d)) * update docker.io/library/alpine docker tag to v3.21.1 ([#3551](#3551)) ([edd5a4c](edd5a4c)) * update docker.io/library/alpine docker tag to v3.21.2 ([#3580](#3580)) ([f577ecd](f577ecd)) * update docker.io/library/maven:3.9.9-eclipse-temurin-11-alpine docker digest to 9a259c6 ([#3554](#3554)) ([eb2cbd6](eb2cbd6)) * update docker.io/library/python:3.13.1-alpine3.20 docker digest to 9ab3b6e ([#3555](#3555)) ([40a74fe](40a74fe)) * update google auth library dependencies to v1.31.0 ([#3577](#3577)) ([7fa879a](7fa879a)) * update googleapis/java-cloud-bom digest to c7c443f ([#3579](#3579)) ([fcf40b7](fcf40b7)) * update repo-automation-bots digest to 0a12b5d ([#3464](#3464)) ([b9c9d21](b9c9d21)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>

rmehta19 added 2 commits January 6, 2025 17:09

initial revert of googleapis#3400.

3d99673

Path googleapis#3401.

9b4b405

product-auto-label bot added the size: m Pull request size is medium. label Jan 7, 2025

This was referenced Jan 7, 2025

fix: plumb mtlsEndpoint to gRPC Channel provider instead of setting it in EndpointContext. #3386

Closed

s2a fix: fix NPE. #3401

Closed

rmehta19 added 3 commits January 6, 2025 17:47

Patch googleapis#3386.

ffa4e7b

change env var name.

b03cb51

fix comment.

451e31b

rmehta19 commented Jan 7, 2025

View reviewed changes

Merge branch 'main' into s2a-integration-roll-forward

494e828

rmehta19 added 2 commits January 7, 2025 08:44

Merge branch 'main' into s2a-integration-roll-forward

22c82ad

Merge branch 'main' into s2a-integration-roll-forward

2ce9003

product-auto-label bot added size: l Pull request size is large. and removed size: m Pull request size is medium. labels Jan 9, 2025

xmenxk reviewed Jan 10, 2025

View reviewed changes

rmehta19 added 2 commits January 13, 2025 08:33

Merge branch 'main' into s2a-integration-roll-forward

e19dad4

declare + define env var one line.

0807a2e

lqiu96 reviewed Jan 13, 2025

View reviewed changes

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java Show resolved Hide resolved

lqiu96 reviewed Jan 13, 2025

View reviewed changes

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java Outdated Show resolved Hide resolved

lqiu96 reviewed Jan 13, 2025

View reviewed changes

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java Outdated Show resolved Hide resolved

rmehta19 added 4 commits January 13, 2025 12:27

remove duplicate builder initialization.

95e70d3

Modify S2A API reflection log message.

b807294

Merge branch 'main' into s2a-integration-roll-forward

882047c

set mtls endpoint for S2A in EndpointContext.

25445d3

lqiu96 reviewed Jan 16, 2025

View reviewed changes

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java Outdated Show resolved Hide resolved

lqiu96 reviewed Jan 16, 2025

View reviewed changes

gax-java/gax-grpc/src/main/java/com/google/api/gax/grpc/InstantiatingGrpcChannelProvider.java Outdated Show resolved Hide resolved

lqiu96 reviewed Jan 16, 2025

View reviewed changes

blakeli0 reviewed Jan 21, 2025

View reviewed changes

rmehta19 mentioned this pull request Jan 21, 2025

feat: add support for new setAllowHardBoundTokens field. #3467

Merged

rmehta19 added 2 commits January 21, 2025 13:01

default withUseS2A doesn't throw an exception.

1703f51

Merge branch 'main' into s2a-integration-roll-forward

22562d6

blakeli0 approved these changes Jan 21, 2025

View reviewed changes

rmehta19 changed the title ~~Revert #3400: Reintroduce experimental S2A integration in client libraries grpc transport~~ feat: revert #3400: reintroduce experimental S2A integration in client libraries grpc transport Jan 22, 2025

resolve merge conflict.

b046dc9

move S2A check to end of determineEndpoint.

6f56cff

rmehta19 added 3 commits January 23, 2025 15:12

update comment above S2A logic in determineEndpoint.

ea4e701

Merge branch 'main' into s2a-integration-roll-forward

fa59ce8

add more detail to S2A comment in determine endpoint.

aa6ba37

lqiu96 merged commit 65a0f11 into googleapis:main Jan 24, 2025
45 of 47 checks passed

release-please bot mentioned this pull request Jan 24, 2025

chore(main): release 2.52.0 #3576

Merged

		String s2AEnv;
		s2AEnv = envProvider().getenv(S2A_ENV_ENABLE_USE_S2A);

	<!-- Ignore method addition to an TransportChannelProvider interface -->
	<!-- Ignore method addition to TransportChannelProvider interface (InternalExtensionOnly) -->

	<!-- Ignore abstract method addition to an EndpointContext -->
	<!-- Ignore abstract method addition to an EndpointContext (InternalApi) -->

feat: revert #3400: reintroduce experimental S2A integration in client libraries grpc transport #3548

feat: revert #3400: reintroduce experimental S2A integration in client libraries grpc transport #3548

Conversation

rmehta19 commented Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rmehta19 commented Jan 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rmehta19 Jan 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rmehta19 Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rmehta19 Jan 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lqiu96 Jan 16, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lqiu96 commented Jan 16, 2025

rmehta19 commented Jan 21, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blakeli0 commented Jan 21, 2025

rmehta19 commented Jan 21, 2025

zhumin8 commented Jan 22, 2025

rmehta19 commented Jan 22, 2025

blakeli0 commented Jan 22, 2025

rmehta19 commented Jan 22, 2025

blakeli0 commented Jan 22, 2025

rmehta19 commented Jan 22, 2025 • edited Loading

lqiu96 commented Jan 23, 2025

rmehta19 commented Jan 23, 2025 • edited Loading

lqiu96 commented Jan 23, 2025

rmehta19 commented Jan 23, 2025

lqiu96 commented Jan 24, 2025 • edited Loading

lqiu96 commented Jan 24, 2025

rmehta19 commented Jan 7, 2025 •

edited

Loading

rmehta19 Jan 13, 2025 •

edited

Loading

rmehta19 Jan 10, 2025 •

edited

Loading

rmehta19 Jan 14, 2025 •

edited

Loading

lqiu96 Jan 16, 2025 •

edited

Loading

rmehta19 commented Jan 22, 2025 •

edited

Loading

rmehta19 commented Jan 23, 2025 •

edited

Loading

lqiu96 commented Jan 24, 2025 •

edited

Loading