Found during the live pass on #265 (PR #271). Pre-existing and not Druid-specific.
src/components/monitoring/tabs/TablesTab.tsx renders Analyze / Vacuum / Reindex buttons for
every row unconditionally — it never reads getCapabilities(). For a provider with
supportsMaintenance: false, every click is answered by /api/db/maintenance with:
HTTP 400 {"error":"Maintenance operations not supported for this database"}
Reproduced live in the running application against Apache Druid 37.0.0.
Who is affected
Both providers that set supportsMaintenance: false:
src/app/api/db/maintenance/route.ts correctly short-circuits on the capability, so nothing dangerous
happens. The problem is that the control exists at all: this is the defect class #194 and #201 were
about — a control that can only ever produce an error.
Why it was not fixed in #271
Gating the tab means threading provider capabilities into TablesTab, which changes behaviour for
every provider at once and needs its own component tests. Doing it inside a provider PR would have
mixed two unrelated changes. docs/providers/druid.md section 8 documents the current behaviour
plainly in the meantime, rather than claiming "no control offers any operation" — which would have
described the intent instead of the software.
Suggested shape
Pass the resolved ProviderCapabilities (or just supportsMaintenance and maintenanceOperations)
into TablesTab, hide the per-row action buttons when maintenance is unsupported, and hide each
individual button whose MaintenanceType is absent from maintenanceOperations. The same check
probably belongs on the Vacuum summary card in that tab's header.
Worth auditing the other monitoring tabs in the same pass for controls that ignore capabilities.
Found during the live pass on #265 (PR #271). Pre-existing and not Druid-specific.
src/components/monitoring/tabs/TablesTab.tsxrendersAnalyze/Vacuum/Reindexbuttons forevery row unconditionally — it never reads
getCapabilities(). For a provider withsupportsMaintenance: false, every click is answered by/api/db/maintenancewith:Reproduced live in the running application against Apache Druid 37.0.0.
Who is affected
Both providers that set
supportsMaintenance: false:src/lib/db/providers/embedded/libredb.ts— has had this since it shippedsrc/lib/db/providers/sql/druid/index.ts— new in feat(db): add Apache Druid provider (Druid SQL over HTTP, no native dependency) #271src/app/api/db/maintenance/route.tscorrectly short-circuits on the capability, so nothing dangeroushappens. The problem is that the control exists at all: this is the defect class #194 and #201 were
about — a control that can only ever produce an error.
Why it was not fixed in #271
Gating the tab means threading provider capabilities into
TablesTab, which changes behaviour forevery provider at once and needs its own component tests. Doing it inside a provider PR would have
mixed two unrelated changes.
docs/providers/druid.mdsection 8 documents the current behaviourplainly in the meantime, rather than claiming "no control offers any operation" — which would have
described the intent instead of the software.
Suggested shape
Pass the resolved
ProviderCapabilities(or justsupportsMaintenanceandmaintenanceOperations)into
TablesTab, hide the per-row action buttons when maintenance is unsupported, and hide eachindividual button whose
MaintenanceTypeis absent frommaintenanceOperations. The same checkprobably belongs on the
Vacuumsummary card in that tab's header.Worth auditing the other monitoring tabs in the same pass for controls that ignore capabilities.