d8dc7c7799
Caught by my own broader test scope after Devin fixes — three test files asserted on user-visible strings that were renamed by the bootstrap PR but the assertions weren't updated: - tests/test_api_query_guardrail.py:110 — asserted `da fetch in suggestion` on /api/query 400 response. Renamed to `agnes snapshot create`. - tests/test_query_materialized_error_message.py:56 — asserted `da sync` in materialized-not-yet error detail. Renamed to `agnes pull`. - tests/test_cli_error_render.py:71 — fixture data + assertion both carried `da fetch`. Updated to `agnes snapshot create`. Plus an actual content miss: docs/setup/claude_settings.json (a template shipped to operators) still installed `da sync` / `da sync --upload-only` hooks. The companion test file (tests/test_setup_hooks_template.py) was asserting that legacy state. Updated both: - Template hooks: `agnes pull --quiet` / `agnes push --quiet` - Test assertions + function name match the new commands
75 lines
2.9 KiB
Python
75 lines
2.9 KiB
Python
"""POST /api/query for a table id that's registered as
|
|
`query_mode='materialized'` but isn't yet a view in `analytics.duckdb`
|
|
returns a helpful, materialize-aware error instead of a raw "Table does
|
|
not exist" string from DuckDB.
|
|
|
|
E2E sub-agent finding 2026-05-01: `agnes query --remote "SELECT * FROM
|
|
e2e2_synced_table LIMIT 5"` on a synced materialized table failed with
|
|
DuckDB's bare error message even though the table is in the registry.
|
|
The fix improves the surfaced message so the operator sees the
|
|
materialize-mode hint without having to decode DuckDB internals.
|
|
"""
|
|
from __future__ import annotations
|
|
|
|
import pytest
|
|
|
|
from src.repositories.table_registry import TableRegistryRepository
|
|
|
|
|
|
def _auth(token: str) -> dict:
|
|
return {"Authorization": f"Bearer {token}"}
|
|
|
|
|
|
def test_query_materialized_id_not_in_views_returns_helpful_message(seeded_app):
|
|
"""An admin querying a materialized id that isn't yet materialized in
|
|
the local analytics.duckdb gets a 400 whose detail names the
|
|
query_mode and points at `da sync` / direct-BQ-query."""
|
|
from src.db import get_system_db
|
|
sys_conn = get_system_db()
|
|
try:
|
|
TableRegistryRepository(sys_conn).register(
|
|
id="not_yet_materialized",
|
|
name="not_yet_materialized",
|
|
source_type="bigquery",
|
|
query_mode="materialized",
|
|
source_query='SELECT 1 FROM bq."ds"."t"',
|
|
bucket="ds",
|
|
source_table="t",
|
|
)
|
|
finally:
|
|
sys_conn.close()
|
|
|
|
c = seeded_app["client"]
|
|
token = seeded_app["admin_token"]
|
|
r = c.post(
|
|
"/api/query",
|
|
json={"sql": "SELECT * FROM not_yet_materialized LIMIT 5"},
|
|
headers=_auth(token),
|
|
)
|
|
assert r.status_code == 400, r.json()
|
|
detail = str(r.json().get("detail", ""))
|
|
# Message should name the table and surface the materialize-mode hint.
|
|
assert "not_yet_materialized" in detail
|
|
assert "materialized" in detail.lower()
|
|
# Either a `agnes pull` hint or a direct-BQ-query hint must appear so the
|
|
# operator has a concrete next step.
|
|
assert "agnes pull" in detail or "bq." in detail
|
|
|
|
|
|
def test_query_unknown_table_falls_back_to_default_error(seeded_app):
|
|
"""Sanity: a query for a table that isn't even in the registry still
|
|
surfaces DuckDB's error verbatim (no false positive on the new hint
|
|
path). RBAC's 403 path takes precedence for non-admin callers; for
|
|
admins (no RBAC filter) the table simply doesn't exist as a view, and
|
|
the query falls through to DuckDB's "does not exist" message."""
|
|
c = seeded_app["client"]
|
|
token = seeded_app["admin_token"]
|
|
r = c.post(
|
|
"/api/query",
|
|
json={"sql": "SELECT * FROM totally_unknown_table"},
|
|
headers=_auth(token),
|
|
)
|
|
assert r.status_code == 400, r.json()
|
|
detail = str(r.json().get("detail", "")).lower()
|
|
# Falls back to the generic query-error path; no materialized hint.
|
|
assert "materialized" not in detail
|