Summary
kbagent search "<term>" --search-type config-based does a literal, case-sensitive substring match against stringified configuration JSON. Because Keboola configs routinely reference the same logical table under different casing (e.g. a component config's row/display name in mixed case vs. the physical/output table name in the resulting storage.input.tables[].source string, which is often all-caps for DB-sourced tables), a case-sensitive search silently misses real references.
Steps to reproduce
- Have an extractor config whose row/display name is mixed-case (e.g.
DCFAmount) but whose resulting Storage table name is uppercase (DCFAMOUNT, common for SQL Server sourced tables).
- Have a second, unrelated config elsewhere in the org reference that table by its uppercase Storage name in
storage.input.tables[].source (e.g. in.c-bucket.DCFAMOUNT).
- Run
kbagent search "DCFAmount" --search-type config-based (org-wide or scoped).
- Run
kbagent search "DCFAMOUNT" --search-type config-based with only the casing changed.
Expected: identical result sets -- a "does this appear anywhere in configuration JSON" search should not depend on casing, especially since the tool's own textual-search mode is documented as "case- and diacritics-insensitive."
Actual: the two queries returned different result counts (5 vs. 13 org-wide in our case), with the mixed-case query missing a real, actively-scheduled daily transformation dependency that the uppercase query found.
Suggested fix: make --search-type config-based case-insensitive by default (matching the behavior already documented for textual search), or at minimum document the case sensitivity prominently in --help so users know to try multiple casings before treating a "no results" as "not used anywhere."
Environment
- OS: Windows 11 Home 10.0.26200
- Shell: Git Bash / PowerShell
- kbagent version: v0.79.0 (auto-updating to v0.80.0 at time of testing; not yet confirmed whether v0.80.0 changes this behavior)
Summary
kbagent search "<term>" --search-type config-baseddoes a literal, case-sensitive substring match against stringified configuration JSON. Because Keboola configs routinely reference the same logical table under different casing (e.g. a component config's row/display name in mixed case vs. the physical/output table name in the resultingstorage.input.tables[].sourcestring, which is often all-caps for DB-sourced tables), a case-sensitive search silently misses real references.Steps to reproduce
DCFAmount) but whose resulting Storage table name is uppercase (DCFAMOUNT, common for SQL Server sourced tables).storage.input.tables[].source(e.g.in.c-bucket.DCFAMOUNT).kbagent search "DCFAmount" --search-type config-based(org-wide or scoped).kbagent search "DCFAMOUNT" --search-type config-basedwith only the casing changed.Expected: identical result sets -- a "does this appear anywhere in configuration JSON" search should not depend on casing, especially since the tool's own textual-search mode is documented as "case- and diacritics-insensitive."
Actual: the two queries returned different result counts (5 vs. 13 org-wide in our case), with the mixed-case query missing a real, actively-scheduled daily transformation dependency that the uppercase query found.
Suggested fix: make
--search-type config-basedcase-insensitive by default (matching the behavior already documented for textual search), or at minimum document the case sensitivity prominently in--helpso users know to try multiple casings before treating a "no results" as "not used anywhere."Environment