fix(post-merge): clean up stale da verbs introduced via #174 merge
Four call sites where #174 (branched from main before the agnes rename fully landed in some files) emitted or referenced `da fetch`. None are operator-visible runtime crashes — but `extractor.py` logs a stale verb to the operator log and `DATA_SOURCES.md` is current docs: - connectors/bigquery/extractor.py:431,434 (operator-facing log line on unverified BQ entity_type — was suggesting `da fetch`). - docs/DATA_SOURCES.md:77,85 (current public docs, two refs to `da fetch` in the workflow + the BQ scope description). - tests/test_cli_query_render.py:7 (module docstring listed `da fetch / agnes schema / etc.` — now `agnes snapshot create / agnes schema / etc.`). - tests/test_cli_snapshot_create.py:1 (docstring referenced `(folded from `da fetch`)` — historical, removed; no value once the rename landed). Pre-existing stale `da` references elsewhere in the branch (templates, operator runbooks, internal comments) are not touched by this commit — they live outside the merge surface and are a separate cleanup task. Verified: 10/10 across the affected test files pass.
This commit is contained in:
parent
e438170ade
commit
8890b6f09b
4 changed files with 7 additions and 7 deletions
|
|
@ -428,11 +428,11 @@ def _init_extract_locked(
|
|||
# Unverified entity type. Skip both the wrap view and
|
||||
# the _meta row. The registry row remains; /api/v2/scan
|
||||
# can still operate from it (builds BQ SQL from
|
||||
# bucket+source_table), and `da fetch` works.
|
||||
# bucket+source_table), and `agnes snapshot create` works.
|
||||
logger.warning(
|
||||
"Unverified BQ entity_type %r for %s.%s.%s — master view skipped. "
|
||||
"Use `da fetch` for this row, or file an issue with a repro to "
|
||||
"request native support.",
|
||||
"Use `agnes snapshot create` for this row, or file an issue with "
|
||||
"a repro to request native support.",
|
||||
entity_type, project_id, dataset, source_table,
|
||||
)
|
||||
continue # Do NOT insert _meta — no inner view to point at.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ bigquery:
|
|||
|
||||
Registers BigQuery tables and views as remote DuckDB views (no data download). Queries
|
||||
issued through the master `analytics.duckdb` are forwarded to BigQuery via the DuckDB
|
||||
BigQuery extension. See also `da fetch` for the analytical workflow that materializes
|
||||
BigQuery extension. See also `agnes snapshot create` for the analytical workflow that materializes
|
||||
filtered subsets locally.
|
||||
|
||||
### Requirements
|
||||
|
|
@ -82,7 +82,7 @@ filtered subsets locally.
|
|||
- DuckDB BigQuery extension (auto-installed by the extractor on first run).
|
||||
- A GCP service account with `bigquery.metadata.get` on the dataset and
|
||||
`bigquery.data.viewer` (or finer) on the table; `bigquery.jobs.create` on the
|
||||
billing project for views and `da fetch` queries.
|
||||
billing project for views and `agnes snapshot create` queries.
|
||||
- Credentials resolution: GCE metadata server first, then Application Default
|
||||
Credentials (`gcloud auth application-default login` or
|
||||
`GOOGLE_APPLICATION_CREDENTIALS`). See `connectors/bigquery/auth.py`.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Three CLI paths surface BQ errors today:
|
|||
- `agnes query --remote` (cli/commands/query.py:_query_remote → /api/query)
|
||||
- `agnes query --register-bq` (cli/commands/query.py:_query_hybrid via
|
||||
RemoteQueryError, which wraps server-side BqAccessError)
|
||||
- `da fetch` / `agnes schema` / etc. (cli/v2_client.V2ClientError → v2 endpoints)
|
||||
- `agnes snapshot create` / `agnes schema` / etc. (cli/v2_client.V2ClientError → v2 endpoints)
|
||||
|
||||
After the refactor they all call cli.error_render.render_error so analyst
|
||||
output is consistent and structured. Closes part of #160 §4.7.3.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
"""Tests for `agnes snapshot create` (folded from `da fetch`)."""
|
||||
"""Tests for `agnes snapshot create`."""
|
||||
|
||||
from typer.testing import CliRunner
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue