[sarkaramrit1993]

Description

SOLR-18589: Collection API commands sent with followAliases=true carry the alias name, and the command resolves it only inside call(), after the lock was taken on the alias name. So DELETEREPLICA collection=myAlias&followAliases=true doesn't serialize with a concurrent command on the real collection. This affects DELETE, DELETESHARD, DELETEREPLICA, SPLITSHARD, MOVEREPLICA, MIGRATE and RENAME, in both Overseer and distributed modes.

Solution

Resolve the alias before computing the lock key (CollectionHandlingUtils.lockCollectionName), in OverseerCollectionMessageHandler.lockTask and DistributedCollectionConfigSetCommandRunner.

Tests

OverseerCollectionConfigSetProcessorTest.testLockTaskResolvesFollowedAlias and the new AliasCollectionApiLockTest (Overseer disabled) fail on main and pass with the fix. The lock, alias, DeleteReplica and collection API suites pass.

@HoustonPutman @dsmiley could you take a look when you get a chance?

[nick-boss-tech]

Hi Amrit,

🤖 AI text below 🤖 (reviewed by Nick Shanin)

I found two follow-up cases while reviewing this and prepared [fixes and regression tests](nick-boss-tech/solr@1edd6a1...52dacc2):

• An alias can change while the command waits for its collection lock. The command then resolves it again and can act on a different collection. The fix checks the resolved source against the acquired lock and returns 409 with a retry message if they differ, preserving the original alias for DELETE/RENAME bookkeeping.
• In Overseer mode, rejecting a multi-collection alias during lock acquisition stores a string where SolrResponse.getException() expects a NamedList, turning the intended 400 into a 500. The fix preserves the structured error for synchronous and asynchronous requests.

At 52dacc23b5bb67d254c111c948733da7bc4a9f81, all six focused tests passed on both seeds (5255C0DE, 18589C0DE). The neighboring suites reported 71 tests, no failures or errors, and one inherited @AwaitsFix(SOLR-13021) skip. That test, CollectionsAPISolrJTest.testCreateAndDeleteShard, passed separately with -Ptests.awaitsfix=true. Tidy and check -x test passed; the root check ran in a full clone with NODE_ENV unset.

With the original production code and the new tests, four tests fail and two controls pass. The queued alias-retargeting test fails by timing out waiting for FAILED; it does not record the final async state.

The tested head is a fast-forward of this PR’s current head. To take the changes:

git switch alias-lock-key-18589
git fetch https://github.com/nick-boss-tech/solr.git solr-18589-submit
git merge --ff-only 52dacc23b5bb67d254c111c948733da7bc4a9f81

[sarkaramrit1993]

Thanks. Took the Overseer error-response fix in 70aafad. Leaving the alias-retarget-during-lock-wait case out of this PR; it predates this change and needs alias updates to coordinate with collection locks.

[nick-boss-tech]

Looks good. 2 comments:
The alias-retargeting race remains, but I accept handling it separately and withdraw it as a blocker here.
The description still overstates REINDEXCOLLECTION coverage.

[sarkaramrit1993]

Dropped REINDEXCOLLECTION from the description; it's LockLevel.NONE so this change doesn't apply to it.