adityamparikh opened a new pull request, #270:
URL: https://github.com/apache/solr-mcp/pull/270
Closes #223. Part of #229.
## What
Every collection tool reports on a single collection, so after a rolling
restart or a scale event nothing answered "which replicas of `films` are down
or recovering, and on which node?". Nothing listed configsets for
`create-collection` either. A new `cluster` package adds:
| Endpoint | What it returns |
|---|---|
| `get-cluster-status` (`collection?`) | `healthy`, `issues`, `liveNodes`,
then `collections` → shards → replicas. Accepts a collection or alias. |
| `list-configsets` | Sorted configset names. The description explains the
`.AUTOCREATED` suffix. |
| `solr://cluster/status` | The same data as JSON, with `{"error": ...}` on
failure (the `getSchemaResource` pattern). |
Both tools are `readOnlyHint` + `idempotentHint`, and every endpoint is
`@PreAuthorize("isAuthenticated()")`.
## How `issues` is computed
These rules apply to **active** shards only. An inactive parent left behind
by `SPLITSHARD` is expected, not a fault.
- A replica whose state is not `active` → `not-active`.
- An active replica on a node missing from `live_nodes` → `node-not-live`.
- A shard with no replica that is active, leader **and on a live node** →
`no-leader`.
`healthy` is `issues.isEmpty()`. It does not use Solr's own `health` field,
because Solr computes that before it cross-checks replicas against live nodes.
The live-node condition on `no-leader` is one step beyond the issue text: a
leader on a dead node cannot serve, even before Solr rewrites its state to
`down`.
`ClusterStatusParser` and its five records are public, so #241 can reuse the
replica data (core name, `baseUrl`, leader) without going through
`ClusterService`'s security proxy. `ReplicaState.baseUrl` is `@JsonIgnore`,
because in the tool output it would just repeat `node`.
The `check-health` and `get-collection-stats` descriptions are rewritten, so
the three health-related tools each name a different job.
## Tests
- `ClusterStatusParserTest`: plain JUnit (no Mockito, so it also runs under
`nativeTest`). It covers each issue rule, inactive shards, a leader on a dead
node, and sort order.
- `ClusterServiceIntegrationTest` (shared single node): `_default`
configset, a healthy new collection with one leader, alias resolution, `not
found` for an unknown collection, and the resource JSON without `baseUrl`.
- `ClusterServiceTwoNodeIntegrationTest`: new
`TwoNodeSolrCloudConfiguration` (ZooKeeper plus two Solr `GenericContainer`s on
one network). It pins `on_node2` to `solr2`, stops `solr2`, and waits up to 90
s for ZooKeeper session expiry. It then asserts that every `on_node2` replica
is reported with `node == solr2:8983_solr`, that each shard gets `no-leader`,
and that `on_node1` stays healthy. Solr 10 reads `SOLR_HOST_ADVERTISE` where
Solr 9 reads `SOLR_HOST`, so the fixture sets both.
- ZooKeeper image pinned as `test-image-zookeeper = "zookeeper:3.9"`
(matching `compose.yaml`) and forwarded as `-Dzookeeper.test.image`, like
`solr.test.image`.
- `McpClientIntegrationTestBase` (HTTP and stdio): both tools are listed
with their hints, and the resource is readable. `McpToolRegistrationTest`
covers `ClusterService` for unique names and `@PreAuthorize`.
`SolrNativeHintsTest` asserts the five record hints by class.
`./gradlew build` passes: 485 tests, 0 skipped. Both cluster integration
tests also pass with `-Dsolr.test.image=solr:9.4-slim` and `solr:10-slim`.
## Docs
README tool and resource tables, the `THREAT_MODEL.md` read-tools row, and
the service and native-hint lists in `AGENTS.md`.
🤖 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]
