epugh opened a new pull request, #4673:
URL: https://github.com/apache/solr/pull/4673
## Summary
- Added an opt-in `ifUnused` query param to `DELETE
/api/configsets/{configSetName}`: when true, the server checks (using its own
cached cluster state, not a client-side scan) whether any collection still
references the configset, and if so skips deletion and reports which
collections are using it, instead of deleting unconditionally. Default behavior
(param omitted) is unchanged — fully backward compatible for existing callers.
- New `DeleteConfigSetResponse` (`deleted: boolean`,
`collectionsUsingConfigSet: List<String>`) so callers get a structured answer
instead of having to infer outcome from an exception.
- `bin/solr delete`'s `deleteCollection`/`deleteCore` now just take a
`SolrClient` rather than building their own `CloudSolrClient` from a ZooKeeper
connection string — the collection-delete flow no longer needs direct ZK
cluster-state access; it now:
- checks collection existence via `CLIUtils.safeCheckCollectionExists` (V2
`CollectionsApi.ListCollections`)
- looks up the collection's configName via the V1 `CLUSTERSTATUS` request
(see note below)
- deletes the collection via `CollectionsApi.DeleteCollection` (V2,
unchanged)
- deletes the configset via the new `ifUnused`-aware
`ConfigsetsApi.DeleteConfigSet` (V2), letting the server do the "is this still
used elsewhere" check with its cached state instead of the CLI doing N
sequential HTTP calls (one per collection) to scan for it.
### Note on the configName lookup
While implementing this, `CollectionsApi.GetCollectionStatus` (V2, `GET
/api/collections/{name}`) turned out to throw under basic-auth-secured clusters
— reproducibly, and independent of this change (confirmed by testing the same
call against a non-secured cluster, where it works fine). The failure is a
`java.lang.AssertionError` in `RTimer.stop()` surfacing through Jersey's
exception-mapping/metrics-filter chain, seemingly unrelated to
configset/collection logic. Rather than build on a broken endpoint,
`DeleteTool` uses the classic V1 `CollectionAdminRequest.ClusterStatus` request
instead — still a plain HTTP admin call (no direct ZK connection), just not the
newest V2 endpoint. Worth its own follow-up investigation/JIRA independent of
this PR.
## Test plan
- [x] `DeleteToolTest` passes, including a new
`testDeleteCollectionSkipsConfigDeleteWhileStillInUse` test: two collections
share a configset, deleting the first with `--delete-config` leaves the
configset intact (still used by the second), deleting the second then actually
removes it
- [x] `DeleteConfigSetAPITest` (unit tests for input validation) updated for
the new method signature
- [x] `TestConfigSetsAPI` (33 tests) and `CollectionsAPISolrJTest` still pass
- [x] `./gradlew :solr:api:spotlessJavaCheck :solr:core:spotlessJavaCheck`
clean
- [x] `./gradlew :solr:api:compileJava :solr:core:compileJava
:solr:core:compileTestJava` clean
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
