fix(connections): enforce scan_enabled:false on explicit scan/ingest commands

scan_enabled:false promised the connection is 'never used as a scan/ingest
target,' but the predicate only gated automatic selection — explicit
ktx scan <id> / ktx ingest <id> still resolved the connection id and reached the
live-database introspection path, so an execute-only connection could still be
scanned or ingested.

Guard runKtxScan and runKtxIngest at entry: if the target connection is
execute-only, refuse with an actionable error (remove the flag to scan, or use
ktx sql to query) before doing any work. This makes the flag a single declaration
honored on every scan/ingest entry point, not just auto-selection.
This commit is contained in:
Andrey Avtomonov 2026-06-09 14:28:05 +02:00
parent f446d207ba
commit 9ac37166f5
5 changed files with 85 additions and 4 deletions

View file

@ -162,10 +162,12 @@ connections:
Set `scan_enabled: false` to register a warehouse for SQL execution only. The
connection is usable by `ktx sql` and the agent `sql_execution` tool, but **ktx**
never introspects, scans, or ingests it — and `ktx setup` validates the
credential without discovering or scanning its schemas. This is the supported way
to run read-only queries against shared or public data (for example a BigQuery
billing project full of unrelated datasets) without making it a context source.
never introspects, scans, or ingests it: automatic ingest skips it, `ktx setup`
validates the credential without discovering or scanning its schemas, and even an
explicit `ktx scan <id>` or `ktx ingest <id>` is refused with guidance. This is
the supported way to run read-only queries against shared or public data (for
example a BigQuery billing project full of unrelated datasets) without making it
a context source.
```yaml
connections: