[Abdulrehman1978]

Fixes #7933

Description of changes

In rust/frontend/src/server.rs, GET /api/v2/tenants/{tenant}/databases and GET /api/v2/tenants/{tenant}/databases/{database}/collections previously used the type aliases ListDatabasesResponse and ListCollectionsResponse in responses(...) (body = ListDatabasesResponse and body = ListCollectionsResponse).

Because utoipa proc-macros operate on syntax tokens without expanding type aliases, utoipa did not know ListDatabasesResponse and ListCollectionsResponse were Vec<Database> and Vec<Collection>. At runtime, utoipa registered a component schema named "Vec" in OpenAPI. Because list_collections was registered after list_databases, the "Vec" schema component was overwritten with the schema of Collection (requiring id, name, configuration_json, tenant, database, log_position, version). As a result, GET /api/v2/tenants/{tenant}/databases declared its response as #/components/schemas/Vec which failed OpenAPI client validation against actual database objects [{"id": "...", "name": "...", "tenant": "..."}].

This PR:

• Replaces body = ListDatabasesResponse with body = Vec<Database> in rust/frontend/src/server.rs.
• Replaces body = ListCollectionsResponse with body = Vec<Collection> in rust/frontend/src/server.rs.
• Updates Hey API generated types in clients/new-js/packages/chromadb/src/api/types.gen.ts to type responses as Array<Database> and Array<Collection>, eliminating the phantom Vec type.
• Adds a unit test test_list_databases_and_collections_openapi_schema to verify both endpoints declare arrays referencing Database and Collection and that no "Vec" schema component is generated.

Test plan

• Tested with cargo test --package chroma-frontend --lib test_list_databases_and_collections_openapi_schema:

  running 1 test
  test server::tests::test_list_databases_and_collections_openapi_schema ... ok
  test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 113 filtered out; finished in 0.02s
  

• Verified cargo check --lib passes in rust/frontend.

Migration plan

None. This is backward-compatible and fixes OpenAPI schema validation for API clients.

Observability plan

Existing metrics and tracing remain unchanged.

Documentation Changes

No user-facing API documentation changes needed; OpenAPI schema now accurately reflects the endpoint response.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)