agnes-the-ai-analyst/tests/test_query_materialized_error_message.py
ZdenekSrotyr 8233c3e3f9 chore(docs): replace stale da verbs and vendor-specific install paths
Sweep operator runbooks (docs/QUICKSTART, docs/HEADLESS_USAGE,
docs/architecture, docs/sample-data, docs/agent-workspace-prompt,
docs/metrics/metrics.yml, dev_docs/server, dev_docs/disaster-recovery),
the corporate-memory service README, the jira connector README + backfill
scripts, the deploy skill, and test docstrings. Replaces `da sync` →
`agnes pull`, `da analyst setup` → `agnes init`, `da metrics ...` →
`agnes catalog --metrics` / `agnes admin metrics ...`, `da fetch` →
`agnes snapshot create`, plus the matching docker-compose admin
invocations.

Vendor-specific `/opt/data-analyst/` install paths in jira backfill /
consistency scripts and operator docs are replaced with the
placeholder `<install-dir>` and a new `AGNES_ENV_FILE` env-var override
that lets a deployment inject its actual install path without a code
change. Aligns with the OSS vendor-agnostic policy in CLAUDE.md.

CHANGELOG `### Internal` entry summarizes the audit and reaffirms the
intentional stale-marker tuples (`_LEGACY_STRINGS`, `_OUR_COMMAND_MARKERS`)
that must keep referencing `da sync` / `da fetch` / etc. for hook upgrade
and override-detection logic.
2026-05-04 21:22:19 +02:00

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 `agnes pull` / 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