CASSSIDECAR-268 Adds endpoint to perform repair for a given keyspace … #231

arjunashok · 2025-06-26T23:51:32Z

…and options

Update 08/28:

Updated repair API to return synchronously without relying on background polling threads until repair completion or max-timeout. The repair invocation's commandId is stored in the job state, which is leveraged by subsequent polling API invocation to determine the job's status.
There exists configuration for retry attempts and interval for the API to retrieve the parent status before responding, to ensure that a repair process has been triggered and to return an accurate status of the process.
Addresses PR comments

Changes

Adds a Sidecar endpoint to support per-keyspace repair operation. API Spec: https://issues.apache.org/jira/browse/CASSSIDECAR-268
Triggers repair asynchronously as a OperationalJob similar to node decommission, leveraging the job-management framework.
Since repairAsync JMX operation is async, the repair job polls for status of the repair operation, to detect completion/failure statuses reported by job status APIs.
Adds related configs repairPollIntervalMillis and maxRepairRuntimeMillis. Latter is used to release sidecar resources after the configured time to recover from unusually long running or wedged repairs.

Open Items (out of scope for this PR. Can be tracked separately)

Publish metrics. eg. repairRunTime, succeeded/failed repairs.

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

client-common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

server/src/main/java/org/apache/cassandra/sidecar/config/RepairConfiguration.java

yifan-c

only scanned through the PR.

yifan-c · 2025-07-09T21:53:54Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

+        catch (OperationalJobConflictException oje)
+        {
+            String reason = oje.getMessage();
+            logger.error("Conflicting job encountered. reason={}", reason);


should the log level be warning or even info? It is not a server error.

The reason this is error is to highlight the cause for a job to be returned as FAILED, which is the outcome of a conflict (consistent with what we're doing with decommission).

I don't have a strong opinion on this and can switch to warn but not info as we would want to highlight this as an unexpected condition if it persists.

Can you log bit more details like keyspace name, table names, tokens , DC etc...?

Add some more details. I'd prefer to add these when we define a conflict policy for repair jobs, which is not currently defined for v1 (See RepairJob.hasConflict())

yifan-c · 2025-07-09T22:03:12Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+            Promise<Boolean> maxWaitTimePromise = Promise.promise();
+            vertx.setTimer(repairConfiguration.maxRepairJobRuntimeMillis(), d -> {
+                LOGGER.info("Timer Poll");
+                maxWaitTimePromise.tryComplete(true);
+            });
+
+            // Promise for completion of repair operation
+            Promise<Void> promise = Promise.promise();
+            Future<Void> resultFut = promise.future();
+
+            // main event loop checks periodically (10s) for completion
+            vertx.setPeriodic(repairConfiguration.repairPollIntervalMillis(), id -> queryForCompletedRepair(promise, cmd));
+            resultFut.onComplete(res -> maxWaitTimePromise.tryComplete(false));
+            Future<Boolean> maxWaitTimeFut = maxWaitTimePromise.future();
+
+            Future<Void> compositeFut = Future.any(maxWaitTimeFut, resultFut)
+                                              // If this lambda below is evaluated, either one of the futures have completed;
+                                              // In either case, the future corresponding to the job execution is returned
+                                              .compose(f -> {
+                                                  LOGGER.info("One of the futures ended waitStatus={} resultStatus={}",
+                                                              maxWaitTimeFut.isComplete(), resultFut.isComplete());
+                                                  boolean isTimeout = (maxWaitTimeFut.succeeded()) ? maxWaitTimeFut.result() : false;
+                                                  if (isTimeout)
+                                                  {
+                                                      LOGGER.error("Timer ran out before the repair job completed. Repair took too long");
+                                                      // TODO: Cancel repair? (Nice to have)
+                                                      // We free up the thread (job fails) and stop polling for completion
+                                                      return Future.failedFuture("Repair job taking too long");


Can you implement this in the asyncResult override?

So, the asyncResult implementation is meant for tracking the execution of a OperationalJob and it's timeout from the handler's standpoint, while executeInternal is specific to the actual job's implementation, where we want to wait based on the job-specific configuration for the asynchronous command.

Also, the timeouts are handled differently - the main job handler succeeds on a job timeout, but the repair job's async repair command fails on the repair timeout.

There are similarities in the implementation, but I figured it is simpler to allow jobs to manage their own timeouts independently.

yifan-c · 2025-07-09T22:12:41Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+    }
+
+    @Override
+    protected void executeInternal()


Since repair is async, you might want to override execute(Promise<Void> promise) instead, completing the parameter promise when repair is complete.
executeInternal() is to run blocking operations.

The base execute method was meant to abstract some of the common job lifecycle management, logging, error handling from job-specific implementations. Separating these also has the advantage of being able to test only the job-specific logic.

I have updated executeInternal's contract to return a Future addressing a prior comment. Lmk if that makes more sense.

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/RepairRequest.java

nvharikrishna

Reviewed it partially, will continue to review it.

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

...rs/adapters-base/src/main/java/org/apache/cassandra/sidecar/adapters/base/RepairOptions.java

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

client/src/main/java/org/apache/cassandra/sidecar/client/SidecarClient.java

server/src/main/java/org/apache/cassandra/sidecar/config/yaml/RepairConfigurationImpl.java

server/src/main/java/org/apache/cassandra/sidecar/config/RepairConfiguration.java

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

nvharikrishna · 2025-07-19T11:42:00Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

+        catch (OperationalJobConflictException oje)
+        {
+            String reason = oje.getMessage();
+            logger.error("Conflicting job encountered. reason={}", reason);


Can you log bit more details like keyspace name, table names, tokens , DC etc...?

server/src/main/java/org/apache/cassandra/sidecar/handlers/data/RepairRequestParam.java

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

nvharikrishna · 2025-07-19T12:14:01Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+                                              });
+            try
+            {
+                compositeFut.toCompletionStage().toCompletableFuture().get(); // wait


periodic task will keep on running if the job has timedout. Need to be cancelled?

With the changes made addressing Yifan's comment that links the PeriodicTask's promise to be handled when the internal future is complete (returned from executeInternal), it should address this concern. Let me know if that is what you are referring to.

.gitignore

...rs/adapters-base/src/main/java/org/apache/cassandra/sidecar/adapters/base/RepairOptions.java

server/src/main/java/org/apache/cassandra/sidecar/handlers/data/RepairRequestParam.java

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

yifan-c · 2025-08-04T21:49:27Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+                default:
+                    String message = String.format("Encountered unexpected repair status: %s Messages: %s", parentRepairStatus, String.join("\n", messages));
+                    LOGGER.error(message);
+                    promise.fail(message);
+                    break;


I do not think you can ever hit this case for switch on enum. Any unrecognized status would fail the statement ParentRepairStatus.valueOf first.

This is more of a catch-all behavior if/when a new enum type is introduced, so it returns a meaningful response.

yifan-c · 2025-08-04T21:51:41Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+        Map<String, String> options = generateRepairOptions(repairParams.requestpayload());
+        String keyspace = repairParams.keyspace().name();
+
+        LOGGER.info("Executing repair operation for keyspace {} jobId={} maxRuntime={}",
+                    keyspace, this.jobId(), config.maxRepairJobRuntime());


I do not find the code that validate the existence of keyspace. It could create unnecessary load on Cassandra process.

Please take a look at org.apache.cassandra.sidecar.handlers.validations.ValidateTableExistenceHandler. You can enhance it to only check for keyspace or add a new validator.

I do not believe keyspace-only existence validation exists. Makes sense to have it's own validator with some abstraction between the two.

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

server/src/test/java/org/apache/cassandra/sidecar/handlers/RepairHandlerTest.java

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

yifan-c · 2025-08-04T22:35:29Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+                                 LOGGER.error("Timer ran out before the repair job completed. Repair took too long");
+                                 return Future.failedFuture("Repair job taking too long");


What is the behavior wanted here? If you want to let the repair on Cassandra to continue and ask client to query for the progress later, I think it is wrong to return a completed (failure) future here. It will complete the executionPromise in OperationalJob, which completes the job.

Yep, valid concern. The current implementation uses a timeout to prevent the sidecar from holding thread resources indefinitely but simply failing the future doesn't provide a good way for clients to continue tracking the repair operation that's still running in Cassandra.

How about a hybrid approach -
Keep the timeout mechanism to release sidecar resources after maxRepairJobRuntime, but change how we handle the timeout. Instead of marking the job as failed on timeout, transition it to a 'DETACHED' state that indicates 'no longer actively monitored by sidecar, but still running in Cassandra'.

Additionally, if we have access to Cassandra's repair session/command ID, it could added to the job response, allowing clients to query/troubleshoot with Cassandra directly for status if needed.

Discussed this offline with @yifan-c . We could potentially leverage the repair vtable to track repair progress instead of polling the async repair operation. Looking into this in more detail as to how it will interoperate with the job management/tracking flow.

Unfortunately, the repair vtable does not exist in 4.0

yifan-c · 2025-08-06T17:57:55Z

I have yet to take another look at the implementation of the async timeout. Just noticed that CHANGES.txt needs to be updated.

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

server-common/src/main/java/org/apache/cassandra/sidecar/common/server/StorageOperations.java

nvharikrishna · 2025-08-11T08:37:03Z

server/src/main/java/org/apache/cassandra/sidecar/config/yaml/RepairJobsConfigurationImpl.java

+        @JsonProperty(value = "max_repair_runtime", defaultValue = DEFAULT_MAX_REPAIR_RUNTIME_MILLIS + "") long maxRepairRuntimeMillis,
+        @JsonProperty(value = "repair_polling_interval", defaultValue = DEFAULT_REPAIR_POLLING_INTERVAL_MILLIS + "") long repairPollIntervalMillis)
+    {
+        this.maxRepairRuntimeMillis = maxRepairRuntimeMillis;


What are the valid values/range for these configs? Shall we add some validation?

Updated these configs in the latest revision. The new configs will have retry attempts which is a int value, and polling interval is a long value in milliseconds. As for validation, what is the concern you have in mind?

It is currently a balance of how defensive we'd like to be, and consistent with other areas where we read configs - i.e. we do not explicitly validate ranges.

nvharikrishna · 2025-08-11T10:02:51Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/validations/ValidationUtils.java

+                       return Future.succeededFuture(keyspaceMetadata);
+                   }
+               }, throwable -> {
+                   context.fail(throwable);


Since it is in utility class, I think it is better to leave it to the caller how to handle the failure. Caller can do additional things if needed (like logging or wrapping it up with HttpException etc...)

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

JeetKunDoug · 2025-10-01T14:55:42Z

@arjunashok can you please rebase this onto the current trunk branch?
Others who have reviewed previously - if you have time, please take a look and make sure everything is in order now? Would love to get this PR merged soon if possible!

nvharikrishna

Reviewed 22/36 files. Few nits, otherwise looks good so far. Thanks for the patience. Will continue the review.

nvharikrishna · 2025-10-06T13:25:53Z

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

+    private final List<String> hosts;
+    private final String startToken;
+    private final String endToken;
+    private RepairType repairType;


can be final?

nvharikrishna · 2025-10-06T13:27:11Z

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java

+    /**
+     * Constructs a new {@link RepairPayload}.
+     */
+    public RepairPayload()


Is it needed? Okay to avoid this constructor so that only builder can build this object?

nvharikrishna · 2025-10-06T13:42:08Z

server/src/main/java/org/apache/cassandra/sidecar/config/RepairJobsConfiguration.java

+public interface RepairJobsConfiguration
+{
+    /**
+     * @return the max retry attempts for the repair job status to be valid


repair job status to be valid

valid here means?

Looks like unused

Renamed to repairStatusMaxAttempts. This holds the no. retries when we fail to get or receive a null status (while initializing) of the repair job.

nvharikrishna · 2025-10-06T13:45:36Z

server/src/main/java/org/apache/cassandra/sidecar/config/yaml/RepairJobsConfigurationImpl.java

+ */
+public class RepairJobsConfigurationImpl implements RepairJobsConfiguration
+{
+    // 1 day in milliseconds


I guess this comment is irrelevant now, isn't it?

nvharikrishna · 2025-10-06T14:14:14Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

+        {
+            String reason = oje.getMessage();
+            logger.warn("Conflicting job encountered for keyspace {}. reason={}", repairRequestParam.keyspace(), reason);
+            context.response().setStatusCode(HttpResponseStatus.CONFLICT.code());


nit: Can’t the fluent API be used?

Leaving this as-is for consistency with other implementations/handlers

nvharikrishna · 2025-10-06T14:39:32Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/RepairHandler.java

+            return;
+        }
+
+        job.asyncResult(executorPools.service(), config.operationalJobExecutionMaxWaitTime())


config.operationalJobExecutionMaxWaitTime() sounded like total time to wait for the job, but it looks the propertry name is operations_job_sync_response_timeout which is more clear. Okay to rename config.operationalJobExecutionMaxWaitTime to reflect sync response timeout ? And can we have upper limit for this value?

so, this is the " total time to wait for the job". I can see why operations_job_sync_response_timeout can be confusing since it refers to a response. Will look into making it more consistent.

client/src/testFixtures/java/org/apache/cassandra/sidecar/client/SidecarClientTest.java

nvharikrishna

Few minor comments

nvharikrishna · 2025-10-08T04:04:08Z

server/src/main/java/org/apache/cassandra/sidecar/modules/CassandraOperationsModule.java

                 schema = @Schema(implementation = StreamStatsResponse.class)))
+    @ProvidesIntoMap
+    @KeyClassMapKey(VertxRouteMapKeys.CassandraRepairRouteKey.class)
+    VertxRoute cassandraRepairRoute(RouteBuilder.Factory factory,


I think it is misplaced (between @Path(ApiEndpointsV1.STREAM_STATS_ROUTE) and cassandraStreamStatsRoute method).

nvharikrishna · 2025-10-08T04:34:12Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+
+            try
+            {
+                commandId = storageOperations.repair(keyspace, options);


I think it would be better to run it using executorPools as it makes a JMX call.

This is being executed on a separate internal thread. The job-management framework does this when any job is being executed.

nvharikrishna · 2025-10-09T14:29:42Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/validations/ValidationUtils.java

+               .compose(keyspaceMetadata -> {
+                   if (keyspaceMetadata == null)
+                   {
+                       return Future.failedFuture("Keyspace " + keyspace + " was not found");


It can be more direct if the promised is failed with an exception (something that sounds like: KeyspaceNotFoundException) instead of a string message checked against "not found". Not intended to insist on it though.

I agree. your suggestion is cleaner and confirms to what we're doing with SchemaUnavailableException. Will update.

nvharikrishna · 2025-10-09T14:41:33Z

server/src/main/java/org/apache/cassandra/sidecar/handlers/validations/ValidationUtils.java

+     * @return a Future that completes with the KeyspaceMetadata if the keyspace exists,
+     *         or fails with an error if the keyspace doesn't exist or an error occurs
+     */
+    public static Future<KeyspaceMetadata> validateKeyspaceExists(InstanceMetadataFetcher metadataFetcher,


validate prefix gives impression that it returns success/failure. requireKeyspaceExists - does it sound better?

nvharikrishna · 2025-10-09T14:44:25Z

server/src/main/java/org/apache/cassandra/sidecar/job/NodeDecommissionJob.java

+    public boolean hasConflict(@NotNull List<OperationalJob> sameOperationJobs)
    {
        String operationMode = storageOperations.operationMode();
        return "LEAVING".equals(operationMode) || "DECOMMISSIONED".equals(operationMode);


I think it should check if any of the current node's replicas are getting decommissioned or not (probably for some other time)

I see what you mean. Will track this optimization in a separate ticket.

nvharikrishna · 2025-10-09T14:51:21Z

server/src/main/java/org/apache/cassandra/sidecar/job/OperationalJob.java

+                    promise.tryComplete();
+                    if (LOGGER.isDebugEnabled())
+                    {
+                        LOGGER.debug("Complete job execution. jobId={} status={}", jobId, status());


can be info message?

nvharikrishna · 2025-10-09T15:31:02Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+     */
+    public enum ParentRepairStatus
+    {
+        IN_PROGRESS, COMPLETED, FAILED, NEW_STATUS


NEW_STATUS - when it is used?

unused. removed.

nvharikrishna · 2025-10-09T15:33:15Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+    @Override
+    protected Future<Void> executeInternal()
+    {
+        final Promise<Void> repairJobPromise = Promise.promise();


I think this promise can be created before starting the periodic task (just before it is needed)

nvharikrishna · 2025-10-09T15:48:42Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+            options.put(RepairOptions.HOSTS.optionName(), String.join(",", hosts));
+        }
+
+        if (repairPayload.startToken() != null && repairPayload.endToken() != null)


What will happen if only one of them is specified?

Curently, it expects both tokens, with the intention to not have silent defaults, since repair is an expensive operation.

I see nodetool command in Cassandra supports specifying one or the other, but it ends up eventually failing for Murmur3 and Random partitioners. For ByteOrdered and OrderPreserving, this should map to the min-token. I'll validate and create a separate Cassandra ticket to investigate this.

nvharikrishna · 2025-10-09T15:52:10Z

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java

+        {
+            try
+            {
+                long startToken = Long.parseLong(repairPayload.startToken());


#231 (comment) this comment is applicable here as well

I see there is a benefit to parsing it here for token range validation to fail-fast. Will switch it to BigInteger just for the validation.

…and options

…d. Address PR comments.

arjunashok marked this pull request as ready for review July 1, 2025 16:30

arjunashok commented Jul 1, 2025

View reviewed changes

server/src/main/java/org/apache/cassandra/sidecar/job/RepairJob.java Outdated Show resolved Hide resolved

yifan-c reviewed Jul 9, 2025

View reviewed changes

client-common/src/main/java/org/apache/cassandra/sidecar/common/ApiEndpointsV1.java Show resolved Hide resolved

yifan-c reviewed Jul 9, 2025

View reviewed changes

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java Outdated Show resolved Hide resolved

yifan-c reviewed Jul 9, 2025

View reviewed changes

server/src/main/java/org/apache/cassandra/sidecar/config/RepairConfiguration.java Outdated Show resolved Hide resolved

yifan-c reviewed Jul 9, 2025

View reviewed changes

nvharikrishna reviewed Jul 13, 2025

View reviewed changes

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/data/RepairPayload.java Outdated Show resolved Hide resolved

nvharikrishna reviewed Jul 13, 2025

View reviewed changes

client-common/src/main/java/org/apache/cassandra/sidecar/common/request/RepairRequest.java Show resolved Hide resolved

nvharikrishna reviewed Jul 16, 2025

View reviewed changes

nvharikrishna reviewed Jul 19, 2025

View reviewed changes

yifan-c reviewed Aug 4, 2025

View reviewed changes

nvharikrishna reviewed Aug 11, 2025

View reviewed changes

arjunashok force-pushed the CASSSIDECAR-268 branch from 788fd89 to ecdae51 Compare August 27, 2025 18:25

arjunashok force-pushed the CASSSIDECAR-268 branch from ecdae51 to 697d2f5 Compare October 3, 2025 18:59

nvharikrishna reviewed Oct 6, 2025

View reviewed changes

nvharikrishna reviewed Oct 9, 2025

View reviewed changes

arjunashok added 11 commits January 1, 2026 12:38

CASSSIDECAR-268 Adds endpoint to perform repair for a given keyspace …

7bfc4bb

…and options

Fix repair config

5bc7db4

Tagging repair integ tests as heavy

94495c0

Fix test

22a4ad3

Bump up no rows written to simulate long-running repair

f120dec

Minor cleanup

c4898c2

Addressing PR comments

cd91585

Address PR comments

e998ca0

Improved empty status handling before repair starts

af91c2a

Update to only perform retries until a valid repair status is receive…

3f5dead

…d. Address PR comments.

Fix checkstyle

cfdd1e0

arjunashok added 4 commits January 1, 2026 12:41

Addressed comments

d0a4097

Addressed comments

3c21d56

Fix config test

076cb7d

Rebase and address PR comments

b98df42

arjunashok force-pushed the CASSSIDECAR-268 branch from 96cb3e0 to b98df42 Compare January 2, 2026 05:03

Fix test

864a888

		LOGGER.error("Timer ran out before the repair job completed. Repair took too long");
		return Future.failedFuture("Repair job taking too long");

CASSSIDECAR-268 Adds endpoint to perform repair for a given keyspace … #231

Are you sure you want to change the base?

CASSSIDECAR-268 Adds endpoint to perform repair for a given keyspace … #231

Uh oh!

Conversation

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

Uh oh!

Update 08/28:

Changes

Open Items (out of scope for this PR. Can be tracked separately)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yifan-c left a comment

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!

Uh oh!

Uh oh!

nvharikrishna left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arjunashok Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

arjunashok commented Jun 26, 2025 •

edited

Loading

arjunashok Aug 6, 2025 •

edited

Loading