Area: app · tenant moves — gap · found via PR review follow-up (#682's own unchecked test-plan box)
Expected: a tenant move that changes only clickhouse.addr drops the tenant's schema registry and rediscovers, the same as a move that changes clickhouse.database — and at least one case proves the whole move against real ClickHouse, not a fake connection.
Actual: every move test varies the database alone against a fake. TestReload_MovedTenantDiscoversTheNewDatabase, _Flat, _FailedDiscoveryIsRetried and _RegistryIsDroppedBeforeTheCacheInvalidation (internal/app/app_test.go:1876,1917,1940,1993) and TestReload_OpsOnlyMovedTenant (internal/app/roles_test.go:161) all build their settings with one addr held constant — databaseSettings(addr, "default") → databaseSettings(addr, "moved_db") — over newFakeClickHouse on a closedAddr(t). No test in tests/integration/ exercises a tenant move at all.
Impact: the address half of the staleness decision is unproven. Pools.Reconcile's contract (internal/chconn/chconn.go:430-436) treats a move "to another address or database" as stale and a username/tls-only move as not stale, so an address-only move is a distinct branch of that contract with no test behind it — and it is the likelier production move (a tenant repointed to a different ClickHouse host, same database name). If it ever stopped being reported stale, #638 would be back for exactly that move: queries and inserts validated against the previous host's schema and run against the new one, with no error.
Note: the registry-drop mechanism is shared, so this is a coverage gap rather than a suspected defect — the address case is documented in Reconcile's own comment.
Related: #638, #583 (story 6), #610
From PR #682's test plan ("Not covered: a move between two real ClickHouse databases … and a move that changes only clickhouse.addr"), filed after it merged; validated by code-read against 9100b459 on 2026-10-01 via /pm-triage.
Area: app · tenant moves — gap · found via PR review follow-up (#682's own unchecked test-plan box)
Expected: a tenant move that changes only
clickhouse.addrdrops the tenant's schema registry and rediscovers, the same as a move that changesclickhouse.database— and at least one case proves the whole move against real ClickHouse, not a fake connection.Actual: every move test varies the database alone against a fake.
TestReload_MovedTenantDiscoversTheNewDatabase,_Flat,_FailedDiscoveryIsRetriedand_RegistryIsDroppedBeforeTheCacheInvalidation(internal/app/app_test.go:1876,1917,1940,1993) andTestReload_OpsOnlyMovedTenant(internal/app/roles_test.go:161) all build their settings with oneaddrheld constant —databaseSettings(addr, "default")→databaseSettings(addr, "moved_db")— overnewFakeClickHouseon aclosedAddr(t). No test intests/integration/exercises a tenant move at all.Impact: the address half of the staleness decision is unproven.
Pools.Reconcile's contract (internal/chconn/chconn.go:430-436) treats a move "to another address or database" as stale and a username/tls-only move as not stale, so an address-only move is a distinct branch of that contract with no test behind it — and it is the likelier production move (a tenant repointed to a different ClickHouse host, same database name). If it ever stopped being reported stale, #638 would be back for exactly that move: queries and inserts validated against the previous host's schema and run against the new one, with no error.Note: the registry-drop mechanism is shared, so this is a coverage gap rather than a suspected defect — the address case is documented in
Reconcile's own comment.Related: #638, #583 (story 6), #610
From PR #682's test plan ("Not covered: a move between two real ClickHouse databases … and a move that changes only
clickhouse.addr"), filed after it merged; validated by code-read against9100b459on 2026-10-01 via /pm-triage.