NodeNorm's /status reports which backend is answering:
{"status": "running", "version": "1.0.0", "backend": "elasticsearch", ...} // nodenorm-es
{"status": "running", "version": "2.5.1", "backend": "redis", ...} // NodeNorm 2.5.1NameRes has no equivalent. /status on the Solr-backed and the Elasticsearch-backed deployments differ only by a word in a human-readable message (checked 2026-08-31):
{"status": "ok", "message": "Reporting results from primary core.", ...} // name-lookup (Solr)
{"status": "ok", "message": "Reporting results from primary index.", ...} // namelookup-esWould you consider adding a backend field (solr / elasticsearch) alongside the existing keys?
In TranslatorSRI/babel-validation each target now declares which backend it is expected to be talking to, and a test holds the deployment to that — the check exists because a target was repointed from one backend to the other and nothing said so, which surfaced two tests away as an unexplained 404. That check covers NodeNorm today; NameRes cannot be covered without a field to read, and matching on the prose in message would be a worse thing to depend on.
Both backends being supported side by side for the foreseeable future is what makes this worth having: telling them apart is how we catch drift between them.
NodeNorm's
/statusreports which backend is answering:{"status": "running", "version": "1.0.0", "backend": "elasticsearch", ...} // nodenorm-es {"status": "running", "version": "2.5.1", "backend": "redis", ...} // NodeNorm 2.5.1NameRes has no equivalent.
/statuson the Solr-backed and the Elasticsearch-backed deployments differ only by a word in a human-readable message (checked 2026-08-31):{"status": "ok", "message": "Reporting results from primary core.", ...} // name-lookup (Solr) {"status": "ok", "message": "Reporting results from primary index.", ...} // namelookup-esWould you consider adding a
backendfield (solr/elasticsearch) alongside the existing keys?In TranslatorSRI/babel-validation each target now declares which backend it is expected to be talking to, and a test holds the deployment to that — the check exists because a target was repointed from one backend to the other and nothing said so, which surfaced two tests away as an unexplained 404. That check covers NodeNorm today; NameRes cannot be covered without a field to read, and matching on the prose in
messagewould be a worse thing to depend on.Both backends being supported side by side for the foreseeable future is what makes this worth having: telling them apart is how we catch drift between them.