fix(indexes): list indexes for a database-scoped connection#164
Merged
Conversation
Connection-wide `indexes list --connection-id <id>` returned empty for a managed database. The scan derived each table's connection id by mapping the `information_schema` label back through `connections list`, but that listing hides database-scoped connections, so a managed database's catalog (surfaced as the internal `__db_*` label) never resolved. The CLI then used the label as an id, the per-table index call 404'd, and `none_if_404` swallowed it into an empty result. Use the caller-supplied `--connection-id` directly for the per-table calls (extracted as `scan_connection_id`): it always resolves, including for a database-scoped connection, and the scan is already filtered to that connection. The label→id map is now built only for the unscoped list-everything case. The server already serves these indexes by id (that's why the `--schema --table` form works); this aligns the connection-wide path with it. Fixes #161
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Clean, well-scoped fix. Using the supplied --connection-id directly is correct because collect_tables already filters the scan to that connection server-side, and skipping the connection_lookup round-trip in the scoped case is a nice touch. Tests cover the meaningful branches.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Codecov flagged the modified connection-wide branch of `list()` as uncovered — it builds its own `Api` internally and prints, so it was never exercisable. Extract the scan into `collect_connection_wide(&Api, …)` and add a mockito test that reproduces the #161 scenario: an `information_schema` row under the internal `__db_*` label, with the per-table indexes endpoint mocked only for the real id. The index resolves via the supplied id; had the scan used the label, it would miss the mock. No behavior change.
Contributor
There was a problem hiding this comment.
Clean, well-scoped fix. The scan_connection_id extraction and the supplied-id-wins logic are correct (tables are already filtered to the connection), and coverage is thorough — branch-level unit tests plus a mockito regression for the __db_* case. Documentation clearly explains the root cause.
eddietejeda
added a commit
that referenced
this pull request
Jun 19, 2026
#170) Whole-workspace `hotdata indexes list` (no `--connection-id`) returned "No indexes found" for indexes on managed databases, even though the connection-scoped path showed them. The unscoped scan enumerates tables via a workspace-wide `information_schema` call and fetches each table's indexes. But that enumeration returns only regular-connection tables — managed-database catalogs never appear there, and `connections list` hides their connections. In a managed-only workspace the scan therefore finds zero tables and reports nothing. Discover managed databases separately: `databases list` -> resolve each `default_connection_id` via `databases get` (in parallel) -> scan each connection scoped, exactly like the `--connection-id` path. Union the result with the regular-connection enumeration; the two sets are disjoint (a managed DB's connection is never returned by `connections list`), so there is no double-counting. Note: this corrects the root-cause analysis in #168. The unscoped `information_schema` enumeration does not return managed-DB rows under `__db_*` labels at all — so the gap was discovery, not label resolution. Verified against production (workspace AgentRyan): unscoped `indexes list` now surfaces all managed-DB indexes; the `--connection-id` path is unchanged. Refs #161, #164. Closes #168. Co-authored-by: Eddie A Tejeda <669988+eddietejeda@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #161
Summary
hotdata indexes list --connection-id <id>returned empty for a managed database, even with a ready index — while the--schema --tableform showed it correctly.Root cause
The connection-wide scan didn't trust the id you passed. It:
/information_schema, which reports a managed database's catalog under an internal__db_*label, thenconnections list— which hides database-scoped connections by design, so the map had no entry, then__db_*label as the connection id →GET /connections/__db_*/tables/.../indexes→ 404 →none_if_404swallowed it → empty.The
--schema --tableform works because it uses the supplied id directly.Fix
Use the caller-supplied
--connection-iddirectly for the per-table index calls (extracted as the pure, unit-testedscan_connection_id). It always resolves — including for a database-scoped connection — and the scan is already filtered to that one connection, so it's correct for every row. The name→id map is now built only for the unscoped, list-everything case.This is a CLI-only fix: the server already serves these indexes by id (that's why
--schema --tableworks). It just aligns the connection-wide path with howindexes create/--schema --tablealready address managed databases.Tests
scan_connection_id: supplied id wins (even over a populated map), maps the label when no id is given, falls back to the label when unmapped. 194 bin tests pass; fmt clean; no new clippy warnings.connections list→[](scoped connection hidden),information_schema→connection: "__db_<suffix>"(the internal label),GET /connections/<real-id>/.../indexes→ returns the index (the fix's premise),GET /connections/__db_<suffix>/.../indexes→ 404 (the old fallback, i.e. the bug).