Report the backend and API version from /status, renaming the Solr index version to index_version

[gaurav]

Closes #296.

Breaking change: /status's version is now the API version

/status already had a top-level version — the Solr index version ("version": 34838). NodeNorm uses version for the frontend version, and the point of this change is that the two services can be checked the same way, so version has been handed to the API version and the Solr index version is now reported as index_version.

Anyone reading the Solr index version out of /status needs to follow the rename. Nothing in this repo did.

What

Two keys, matching NodeNorm's /status (NCATSTranslator/NodeNormalization#392, issue NCATSTranslator/NodeNormalization#377):

key	value	why
backend	always "solr" here	The Elasticsearch-backed NameRes at biothings/NameResolutionAPI reports "elasticsearch". Until now the two deployments differed only by a word of prose in message ("...primary core." vs "...primary index."), so nothing machine-readable said which implementation answered.
version	the OpenAPI info.version verbatim ("1.7.0")	Lets a caller tell when the API changed without fetching /openapi.json, under the same key NodeNorm uses.

nameres_version ("v1.7.0", the v-prefixed spelling) is unchanged, for consumers that already read it.

{
  "status": "ok",
  "message": "Reporting results from primary core.",
  "backend": "solr",
  "version": "1.7.0",
  ...
  "nameres_version": "v1.7.0",
  ...
  "index_version": 34838,
  "segmentCount": 57
}

Decisions and gotchas

• version comes from get_app_info(), not app.openapi_schema. NodeNorm's version of this read app.openapi_schema["info"]["version"]; here that attribute is None until the first request to /openapi.json (see the app.openapi gotcha in CLAUDE.md, Restore the x-translator, contact and termsOfService OpenAPI metadata dropped by FastAPI 0.137.0 #294), so /status would report "unknown" on a fresh process. status() already called get_app_info(), which reads the same openapi.yml the served spec is built from.
• Both branches of status() report backend and version. The error branch (Expected core not found.) is what a mis-pointed or still-loading deployment returns, and is exactly when a caller most needs to know which NameRes it reached. To make divergence impossible rather than merely intended, the shared keys are now built once as common and spread into each return.
• The test pins version against the served spec, not a literal. tests/test_status.py asserts status['version'] == client.get("/openapi.json").json()['info']['version'], so the identity between the two is actually tested and the assertion doesn't need editing on every version bump. tests/test_openapi.py asserted nothing about info.version before this.

Follow-on work

• api/resources/openapi.yml is still at 1.7.0. The API.md note says index_version was version "before NameRes v1.8.0" (this issue's milestone), so bump it when the release is cut.
• No release notes: releases/ stops at v1.5.2 and has no 1.6/1.7 entries.
• The rename should be picked up in TranslatorSRI/babel-validation, which is the consumer this was built for.

Tests

python -m pytest tests/ — 53 passed against a local Solr with the 89-doc test index. The error branch was verified by hand against a mocked two-core Solr response (so the single-core fallback doesn't rescue it); it carries backend and version.

🤖 Generated with Claude Code