SOLR-17725: CoreAdmin API to upgrade an index in-place to facilitate Solr upgrade across major versions #3903

rahulgoswami · 2025-11-30T06:20:37Z

https://issues.apache.org/jira/browse/SOLR-17725

Description

Provide a /admin/cores api (action=UPGRADECOREINDEX) to upgrade older lucene segments to latest version (by targeted reindexing). Calling this REST endpoint on an index created in version X-1 (assuming you are on Solr version X) would reindex documents in any segments of the older version (X-1) so that they are re-written in version X. This would help prepare the index for when Solr is upgraded to X+1 without having to recreate the index from source (as is the requirement today).

Solution

This API helps to upgrade an index where all fields are either stored or docValues enabled or copy field target.

Here's the algorithm:

Set the merge policy as LatestVersionMergePolicy (which is a filter merge policy that delegates to whichever policy is actual defined in solrconfig or the TieredMergePolicy by default). This policy filters out any segments with minVersion=X-1 and only allows the latest version (X) segments to participate in merges. This ensures that the older version segments don't merge and "pollute" the index over the course of the reindexing.
Iterate over the segments and for any segment which is a pure X-1 version segment (result of flush; minVersion=X-1, version=X-1) or a result of merge between version X-1 and X segments (minVersion=X-1, version=X), reindex all live documents in the segment.
commit and validate that all segments in the index have been converted to version X.
Reset the merge policy back to the original merge policy.

This works because after the change in apache/lucene#14607 (and the backport to 10x) opening an index no longer cares about which version the index was originally created in. Lucene just needs all of the segments to be of version X or later in order to be able to open the index in version X+1 (even though the index could have been originally created in version X-1)

[AI Coding Tools Disclosure: Only use of AI coding tools was in the tests (UpgradeCoreIndexActionTest.java). Claude Code and OpenAI Codex were used to generate, review, iterate and fix the tests mentioned in the "Tests" section. The same were also manually reviewed thereafter for correctness. ]

Tests

For an index with below segments:
seg1 - pure 9x
seg2 - pure 10x
seg3 - minVersion 9x, version 10x (result of merge between 9x and 10x segements)

seg1 and seg3 get reindexed into new 10x segment, and get deleted. seg2 remains untouched (as expected).

DocValues-only fields are preserved during reindexing (this is tested specifically since we are reading docs from segments and decorating the SolrInputDocument with docValues thereafter)
older segments get deleted by the end of the process
async mode works fine. Tested by calling /admin/cores?action=UPGRADECOREINDEX&async=request_id. And later calling action=REQUESTSTATUS&requestid=request_id
For an index where all segments belong to the latest major version, calling the UPGRADECOREINDEX API is a no-op, and returns "upgradeStatus":"NO_UPGRADE_NEEDED" in the response.

Checklist

Please review the following and check all that apply:

I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
I have created a Jira issue and added the issue ID to my pull request title.
I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
I have developed this patch against the main branch.
I have run ./gradlew check.
I have added tests for my changes.
I have added documentation for the Reference Guide
I have added a changelog entry for my change

rahulgoswami · 2025-11-30T06:27:17Z

First (half-baked) draft. WIP.

…ion for custom update.chain

rahulgoswami · 2025-12-23T06:50:10Z

Looking good. Basic (manual) tests with /admin/cores?action=UPGRADECOREINDEX working fine. Will publish response with segment status before and after index upgrade. Also need to add tests.

… has been renamed. It's being used in this feature..

rahulgoswami · 2026-01-02T02:42:19Z

@dsmiley @broustant @janhoy This is ready for review. Would appreciate your inputs. Thanks!

…gments reliably

…keep forbiddenApisTest happy

dsmiley

Partial review.

Thanks for working on this!

@broustant you may find some of this rather familiar from index encryption

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

dsmiley · 2026-01-07T05:37:20Z

solr/api/src/java/org/apache/solr/client/api/model/UpgradeCoreIndexRequestBody.java

+
+  @Schema(description = "Request ID to track this action which will be processed asynchronously.")
+  @JsonProperty
+  public String async;


Maybe @gerlowskija might review the V2 API spect.

But what I notice here is this async --- I'm suspicious as I figure it'd be handled in a more general way without each command needing to redundantly specify it, which is basically all commands.

I have tested this with only V1 api so far, but have tried to follow the pattern for V2 as well. There might be gaps which @gerlowskija could point out (?). In case of v1, the async is handled by the CoreAdminHandler.handleRequestBody() itself by adding to CoreAdminAsyncTracker https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java#L231

Right now unlike the SolrJerseyResponse, the *RequestBody classes don't inherit from a common parent so each one seems to introduce the "async" by itself. Perhaps a case for refactoring and pushing "async" into the parent class? An action item for another PR?

dsmiley · 2026-01-07T05:39:04Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+        coreName,
+        requestBody.async,
+        "upgrade-index",
+        () -> {


a stylistic point but this lambda is way too big; please use another technique like define a method, and call it with a one-liner lambda.

dsmiley · 2026-01-07T05:40:33Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+        () -> {
+          try (SolrCore core = coreContainer.getCore(coreName)) {
+
+            log.info("Received UPGRADECOREINDEX request for core: {}", coreName);


Logging at request level seems like a framework infrastructure level concern (probably already logged), not one unique to this particular command

dsmiley · 2026-01-07T05:42:14Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+            int numSegmentsEligibleForUpgrade = 0, numSegmentsUpgraded = 0;
+            try {
+              iwRef = core.getSolrCoreState().getIndexWriter(core);
+              if (iwRef != null) {


Surely this can't be null?!

dsmiley · 2026-01-07T05:57:41Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+              if (iwRef != null) {
+                IndexWriter iw = iwRef.get();
+                if (iw != null && originalMergePolicy != null) {


again; null checks needless

iwRef null-check might be needed in case there is an exception getting the IndexWriter in try for whatever reason (eg:AlreadyClosedException). Removed the null check on "iw".

dsmiley · 2026-01-07T06:02:28Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+      if (resolvedChain != null) {
+        return resolvedChain;
+      } else {
+        log.error(


I think this should throw an error (and not log)

dsmiley · 2026-01-07T06:05:47Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+    // Try to find chain configured in /update handler
+    String updateChainName = null;
+    SolrRequestHandler reqHandler = core.getRequestHandler("/update");
+
+    NamedList initArgs = ((RequestHandlerBase) reqHandler).getInitArgs();
+
+    if (initArgs != null) {
+      // Check invariants first
+      Object invariants = initArgs.get("invariants");
+      if (invariants instanceof NamedList) {
+        updateChainName = (String) ((NamedList) invariants).get(UpdateParams.UPDATE_CHAIN);
+      }
+
+      // Check defaults if not found in invariants
+      if (updateChainName == null) {
+        Object defaults = initArgs.get("defaults");
+        if (defaults instanceof NamedList) {
+          updateChainName = (String) ((NamedList) defaults).get(UpdateParams.UPDATE_CHAIN);
+        }
+      }
+    }


I think we're trying too hard to find the default chain. If it's actually this hard, then this code should live elsewhere and we just call it. But I'm still suspicious. If it wasn't so late I'd go look.

dsmiley · 2026-01-07T06:06:50Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+
+  private boolean isIndexUpgraded(SolrCore core) throws IOException {
+
+    try (FSDirectory dir = FSDirectory.open(Path.of(core.getIndexDir()));


woah woah... lets instead get the Directory from the factory from the core. See SolrIndexSplitter.

good catch!

dsmiley · 2026-01-07T06:08:05Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+
+  private void doCommit(SolrCore core) throws IOException {
+    try (LocalSolrQueryRequest req = new LocalSolrQueryRequest(core, new ModifiableSolrParams())) {
+      CommitUpdateCommand cmd = new CommitUpdateCommand(req, false);


please add a little EOL comment on what "false" means

rahulgoswami · 2026-01-08T04:36:16Z

@dsmiley Thanks for an initial review. I am working on addressing the review comments.

… logging

dsmiley · 2026-01-10T19:57:26Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

 import org.slf4j.LoggerFactory;

+/**
+ * Implements the UPGRADECOREINDEX CoreAdmin action, which upgrades an existing core's index


I appreciate your time writing this but a user isn't going to read this, only someone maintaing this code will. ref-guide documentation is for our users.

I understand, and I did debate this. But eventually decided to be more verbose and spell out the high-level algorithm for anyone looking at the code. In my opinion, it might not hurt to keep certain implementation details in their current form in the javadoc(?). Edited to leave out certain details/notes more suitable for ref-guide.

dsmiley · 2026-01-10T20:09:55Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+
+    LeafReader leafReader = FilterLeafReader.unwrap(leafReaderContext.reader());
+    SegmentReader segmentReader = (SegmentReader) leafReader;
+    final String segmentName = segmentReader.getSegmentName();


This line is the only reason why you casted leafReader to a segmentReader. And this variable is only used in logging. It'd be a shame to limit the functionality of this tool to require full unwrapping of the reader. Just log the leafReader instead? Or add a utility method used in logging to get a "pretty" name for the leaf reader that attempts to get the name by unwrapping.

dsmiley · 2026-01-10T20:10:36Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+    String coreName = core.getName();
+    IndexSchema indexSchema = core.getLatestSchema();
+
+    LeafReader leafReader = FilterLeafReader.unwrap(leafReaderContext.reader());


Lets not unwrap; it limited the range of uses of this tool. For example, maybe we want UninvertingReader to synthesize docValues from the index!

We now get the leaves from the raw reader (searcher.getRawReader()), so I don't think it would have the ExitableDirectoryReader or UninvertingReader wrappers anymore. Got rid of unwrapping anyway to simplify the code.

dsmiley · 2026-01-10T20:12:52Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+    Bits bits = segmentReader.getLiveDocs();
+    SolrInputDocument solrDoc = null;
+    UpdateRequestProcessor processor = null;
+    LocalSolrQueryRequest solrRequest = null;


Can you put this into try-with-resources to avoid the explicit close?

Refactored processSegment() to avoid belt-and-suspenders exception handling

dsmiley · 2026-01-10T20:34:40Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+    LeafReader leafReader = FilterLeafReader.unwrap(leafReaderContext.reader());
+    SegmentReader segmentReader = (SegmentReader) leafReader;
+    final String segmentName = segmentReader.getSegmentName();
+    Bits bits = segmentReader.getLiveDocs();


the name of this variable is terrible; it's like calling a String as string. The only name for this is liveDocs

dsmiley · 2026-01-10T20:44:43Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+  /*
+   * Convert a lucene Document to a SolrInputDocument
+   */
+  protected SolrInputDocument toSolrInputDocument(


This code looks duplicative of similar code in RealtimeGetComponent. Right? Can we dedupulicate?

The code in RealTImeGetComponent creates SolrInputDocument out of SolrDocument, whereas here I am directly creating SolrInputDocument from Lucene Document.
Looking at this though, I am revisiting if this code will work for nested documents. I may have to make additional modifications to accommodate that. We don't use them, so I have limited knowledge about the internal heuristics of nested docs. Reading up more to decide whether further changes are needed.

It's okay to punt on this. Detect that the schema advertises support for nested docs -- and then fail.

Doing this properly requires reading the linear/adjacent series of docs and reconstruct the hierarchy. This way, the URPs "see" what they are supposed to see -- the root of the hierarchy. And Solr will do it's behavior of linearalizing them at the end and adding them in an atomic fashion, which is critical.

Ok. I have added the change to bail out if nested docs are detected. I went for detecting actual presence of nested docs instead of schema.isUsableForChildDocs() since sometimes people derive a schema out of examples and it may contain _root_ field even though they don't have any nested docs really.

Also added a test for the same.

dsmiley · 2026-01-10T20:47:06Z

solr/core/src/test/org/apache/solr/handler/admin/UpgradeCoreIndexActionTest.java

+  }
+
+  @AfterClass
+  public static void afterClass() {


Solr's test infrastructure resets/clears all system properties at the end of each test. So you can remove this and stop bothering saving the directory. @epugh is at present removing all trace of such from tests you might have gotten inspiration from

dsmiley · 2026-01-10T20:52:39Z

solr/core/src/test/org/apache/solr/handler/admin/UpgradeCoreIndexActionTest.java

+import org.junit.BeforeClass;
+import org.junit.Test;
+
+public class UpgradeCoreIndexActionTest extends SolrTestCaseJ4 {


Could you please consider using EmbeddedSolrServerTestRule with SolrTestCase base class (not STCJ4) instead? I'm slowly trying to move our tests to be SolrClient based and away from STCJ4. Your test hear seems ripe for it.

dsmiley · 2026-01-10T20:54:20Z

solr/core/src/test/org/apache/solr/handler/admin/UpgradeCoreIndexActionTest.java

+
+    final Set<String> segmentsBeforeUpgrade = listSegmentNames(core);
+
+    CoreAdminHandler admin = new CoreAdminHandler(h.getCoreContainer());


This is invasive... like why can't you send a normal looking request into Solr in a SolrJ/SolrClient way without needing to directly manipulate Solr server classes like this. This gets to my suggestion at the class declaration about using a SolrClient instead -- encourages client side approach. Only reach into Solr internals when actually needed to accomplish a goal.

dsmiley · 2026-01-10T20:55:54Z

solr/core/src/test/org/apache/solr/handler/admin/UpgradeCoreIndexActionTest.java

+  }
+
+  private Set<String> listSegmentNames(SolrCore core) {
+    RefCounted<org.apache.solr.search.SolrIndexSearcher> searcherRef = core.getSearcher();


have you seen core.withSearcher? More elegant.

…Throw error when updateChain not found

…ame for liveDocs

… avoid belt-and-suspenders exception handling

rahulgoswami · 2026-01-13T05:56:09Z

Thanks for the thoughtful review comments. Addressed many of them. Still working on the rest. Shall update soon.

…(); cleanup test to not require FSDirectory anymore; make javadoc more concise; remove extra block in parenthesis in performUpgrade()

dsmiley

Thanks for your improvements

dsmiley · 2026-01-16T14:22:34Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+        RefCounted<SolrIndexSearcher> searcherRef = core.getSearcher();
+        try {
+          List<LeafReaderContext> leafContexts = searcherRef.get().getRawReader().leaves();


I could imagine it's very useful to benefit from UninvertingReader but you chose getRawReader.

I took a hint from your earlier comment :)

think the code here could learn some things from long lived code in SolrIndexSplitter. It uses searcher.getRawReader().leaves() to bypass ExitableDirectoryReader and uninverting.

But I see your point. UninvertingReader would give the ability to even retain indexed-only fields (stored=false, docValues=false). I like it! Might add that support later. Leaving the door open for now by switching to searcher.getIndexReader() instead. thanks!

dsmiley · 2026-01-16T14:41:48Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+  private UpgradeCoreIndexResponse performUpgrade(
+      String coreName, UpgradeCoreIndexRequestBody requestBody, UpgradeCoreIndexResponse response) {
+
+    try (SolrCore core = coreContainer.getCore(coreName)) {


you could drop yet another level of indentation by extracting another method

dsmiley · 2026-01-16T14:48:09Z

solr/core/src/java/org/apache/solr/handler/admin/api/UpgradeCoreIndex.java

+
+          docFetcher.decorateDocValueFields(
+              solrDoc, leafReaderContext.docBase + luceneDocId, nonStoredDVFields, dvICache);
+          solrDoc.removeField("_version_");


Reminder: suspicious removal; at least needs a comment

I'll get back on this. I roughly remember running into some error in some scenario with _version_ intact. Can't remember if it was with specific field attributes. Tests pass fine with _version_ intact. Will try to recall again in the morning and address this either way.

Fixed this. I conflated this with another scenario where I was forwarding a doc from one core to another one with the same id. And that throws an error if it contains the _version_ field since the doc doesn't exist in the other core ("version conflict for id_blah expected=1854703490865037312 actual=-1").

In this case, since it is on the same core and the document already exists (obviously), it should be retained in order to prevent possible race condition during reindexing in case there is a concurrent update that comes in. silly silly silly oversight!

Thanks for flagging this and for the reminder!

…o benefit from UninvertibleReader wrapper

…adeCoreIndex.performUpgrade() further to reduce indentation levels

rahulgoswami · 2026-01-28T07:37:00Z

@dsmiley The review comments have been addressed. Can you please take another look? Thanks.

rahulgoswami and others added 3 commits November 20, 2025 03:11

Add merge policy to block older segments from participating in merges

1ea5cce

extend FilterMergePolicy for delegation and modularize logic

cdc9978

First draft: Add UPGRADECOREINDEX as a CoreAdmin API

4be5ca1

github-actions bot added client:solrj cat:index cat:api labels Nov 30, 2025

rahulgoswami changed the title ~~CoreAdmin API to upgrade an index in-place to facilitate Solr upgrade across major versions~~ SOLR-17725: CoreAdmin API to upgrade an index in-place to facilitate Solr upgrade across major versions Nov 30, 2025

rahulgoswami marked this pull request as draft November 30, 2025 06:24

rahulgoswami added 2 commits November 30, 2025 01:55

fix incorrect early-exit while iterating over segments

052cda6

merge with main

faff01f

github-actions bot removed the cat:index label Dec 9, 2025

rahulgoswami added 2 commits December 12, 2025 02:13

restore original merge policy; injectable factory for test stubs; opt…

c9e3f3e

…ion for custom update.chain

cleanup and optimizations

daaaecb

rahulgoswami force-pushed the index-upgrade branch from 3085bea to daaaecb Compare December 12, 2025 07:14

rahulgoswami added 10 commits December 12, 2025 02:22

more cleanup

1fa4f2a

get default update chain if update.chain is not defined for /update

de455df

fix getUpdateProcessorChain()

c98418b

gradlew tidy

57b5842

fix getUpdateProcessorChain()

abd584e

1) incorrect LeafReader closure.2) Fix validation

bdfa291

cleanup

feb70ac

interrupt handling and validation cleanup

393c081

async mode may cause merge policy to be reset immediately

b335e8e

Fix null response

6a354fd

rahulgoswami marked this pull request as ready for review December 23, 2025 06:50

changelog

088c599

rahulgoswami mentioned this pull request Dec 29, 2025

Rename LatestVersionMergePolicy for a more intuitive name compatibility with the factory #3986

Closed

8 tasks

Merge branch 'main' into index-upgrade since LatestVersionMergePolicy…

dfd7786

… has been renamed. It's being used in this feature..

rahulgoswami added 3 commits January 1, 2026 18:41

Wrap exceptions in CoreAdminAPIBaseException

0f10339

Wrap exceptions in CoreAdminAPIBaseException

b8b5deb

Handle exceptions in processSegment to preserve the main failure

983f2d6

rahulgoswami added 2 commits January 2, 2026 03:15

keeping validateLogCalls and forbidden apis check happy

d005712

Add UPGRADECOREINDEX to ref guide for CoreAdmin API

c8f2df2

github-actions bot added the documentation Improvements or additions to documentation label Jan 4, 2026

rahulgoswami added 3 commits January 5, 2026 00:41

do UpdateHandler.commit() instead of IndexWriter.commit() to clear se…

ee5d1e2

…gments reliably

add tests

b53dec1

Use VarHandle instead of reflection in UpgradeCoreIndexActionTest to …

d7faaa4

…keep forbiddenApisTest happy

github-actions bot added the tests label Jan 6, 2026

Add license

b68f587

dsmiley reviewed Jan 7, 2026

View reviewed changes

Added javadoc for UpgradeCoreIndex; Removed redundant null checks and…

58b25b3

… logging

dsmiley reviewed Jan 10, 2026

View reviewed changes

rahulgoswami added 4 commits January 10, 2026 23:58

Modularize lambda; Fix typos

1e48deb

Push calculation of eligible segments into the main processing loop; …

361b248

…Throw error when updateChain not found

Use getRawReder() instead of getTopReaderContext(); better variable n…

68038ee

…ame for liveDocs

Refactor processSegment to handle close() through try-with-resources;…

99136e8

… avoid belt-and-suspenders exception handling

rahulgoswami added 2 commits January 14, 2026 02:57

Used directoryFactory from the core for validation in isIndexUpgraded…

39c91cc

…(); cleanup test to not require FSDirectory anymore; make javadoc more concise; remove extra block in parenthesis in performUpgrade()

Avoid unncessary unwrapping in processSegment()

c464e40

dsmiley reviewed Jan 16, 2026

View reviewed changes

rahulgoswami added 5 commits January 18, 2026 03:58

Switch to using searcher.getIndexReader() (instead of getRawReader) t…

83b2dd0

…o benefit from UninvertibleReader wrapper

Don't remove _version_ field

023e6fa

Readability changes: Use core.withSearcher() in tests; decompose Upgr…

bbb52d6

…adeCoreIndex.performUpgrade() further to reduce indentation levels

Bail out if index contains nested docs; Add test

a8bbe76

Include note about nested docs

b3edeb5


		private boolean isIndexUpgraded(SolrCore core) throws IOException {

		try (FSDirectory dir = FSDirectory.open(Path.of(core.getIndexDir()));


		final Set<String> segmentsBeforeUpgrade = listSegmentNames(core);

		CoreAdminHandler admin = new CoreAdminHandler(h.getCoreContainer());

SOLR-17725: CoreAdmin API to upgrade an index in-place to facilitate Solr upgrade across major versions #3903

Are you sure you want to change the base?

SOLR-17725: CoreAdmin API to upgrade an index in-place to facilitate Solr upgrade across major versions #3903

Conversation

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

Uh oh!

Description

Solution

Tests

Checklist

Uh oh!

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

Uh oh!

Uh oh!

rahulgoswami commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rahulgoswami commented Jan 2, 2026

Uh oh!

dsmiley left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rahulgoswami Jan 10, 2026 • 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!

rahulgoswami Jan 10, 2026 • 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!

rahulgoswami commented Jan 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rahulgoswami Jan 14, 2026 • 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!

rahulgoswami Jan 13, 2026 • 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!

rahulgoswami Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

rahulgoswami commented Nov 30, 2025 •

edited

Loading

rahulgoswami commented Nov 30, 2025 •

edited

Loading

rahulgoswami commented Dec 23, 2025 •

edited

Loading

rahulgoswami Jan 10, 2026 •

edited

Loading

rahulgoswami Jan 10, 2026 •

edited

Loading

rahulgoswami Jan 14, 2026 •

edited

Loading

rahulgoswami Jan 13, 2026 •

edited

Loading

rahulgoswami Jan 28, 2026 •

edited

Loading

rahulgoswami Jan 18, 2026 •

edited

Loading

rahulgoswami Jan 18, 2026 •

edited

Loading

rahulgoswami Jan 19, 2026 •

edited

Loading