[gaurav]

Builds on #42 — review only the last four commits (from "Let handlers write a top-level JSON list" on). Until #42 merges, this PR's diff against main includes it.

POST /get_setid answers with an object keyed by input index ({"0": {...}, "1": {...}}) because Tornado refuses to write a top-level list. NodeNorm Redis returns a list, and the clients were written against it. This PR lets NodeNormalizationBaseHandler write lists, and then returns the SetIDResponse objects as a list in input order, as the OpenAPI document now says. This is a breaking change for any client of NodeNorm ES that reads body["0"].

Calls worth overruling

• Lists are allowed in the base handler, not serialized by hand in one handler. Tornado's refusal guards against JSON hijacking through <script> tags in very old browsers, which doesn't matter for a public JSON API that allows any origin. Allowing lists in the base handler means the next handler that returns a list doesn't hit the same 500 /get_allowed_conflations did. The comment on write() in handlers/base.py says why.
• The sets in one POST are normalized concurrently with asyncio.gather. One POST can now make as many concurrent Elasticsearch requests as it has sets (see Is there a limit to how many simultaneous CURIEs NodeNorm ES can support? #22 on cluster load). It's the last commit, so it can be dropped on its own.
• info.version stays at 1.1.0, the bump in Rewrite the OpenAPI document to describe the Elasticsearch service, and make the endpoints match it #42, on the assumption that both PRs ship in the same release. If Rewrite the OpenAPI document to describe the Elasticsearch service, and make the endpoints match it #42 is deployed first, this one should bump it again, because /status reports it.

What's here

• POST /get_setid returns a JSON array; the unreachable "empty result → 500" check after the loop is gone. The OpenAPI document's 200 response for it is now an array of SetIDResponse.
• A unit test for the base handler's list output, and a POST unit test in tests/test_openapi.py that mounts the handler with a fake generate_setid() patched through unittest.mock, so the fake doesn't leak into tests/test_set_identifiers.py when pytest-randomly runs that later. Rewrite the OpenAPI document to describe the Elasticsearch service, and make the endpoints match it #42's tests of the POST errors now read the list, and cover an empty body as well.
• The integration test in tests/test_set_identifiers.py expects a list.

What it deliberately does not do

The POST body checks (400 for a body that isn't a non-empty JSON array of objects) and the generate_setid() fixes for unknown conflations and empty sets are in #42, not here.

Verification

On 22f1970, openapi-spec-validator passes, and the whole suite passes under several random orderings except the four integration tests that need the su10 host: test_node_normalization_get and test_node_normalization_post in test_normalized_nodes.py, and test_get_endpoint and test_post_endpoint in test_set_identifiers.py. So the list-expecting integration test hasn't been run.

Nothing is blocking beyond #42 merging first.

🤖 Generated with Claude Code