You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A Snowflake table whose name contains Japanese characters or # scans, approves (via Approve source) and induces fine, but any Playground question that targets it fails. Depending on how the LLM quotes the identifier, the failure happens at three different places — none of which is surfaced to the user. Playground always answers with a generic "the provided context does not contain information about …", so the user cannot tell that a query was generated and rejected.
Environment
Commit ID: Observed on 42b5c6b (tag v0.2.2). sql_generator.py / sql_firewall.py / the discovery path are unchanged on e265573 (tag v0.3.1 = main).
Check the context-manager log group and the Athena workgroup history — the failures below are only visible there
A root cause
Same root, three failure points:
Generated SQL
Where it dies
Evidence
… FROM 売上#2024 (unquoted, #)
COA's own SQL firewall: sqlglot.parse_one() raises ParseError → sql_firewall_parse_error → treated as unsafe_sql_attempt and discarded. Athena is never called.
Athena query-execution record (see below); this is the exact message the customer reported
Athena query-execution record for the third case:
Query: SELECT COALESCE(SUM(AMOUNT), 0) AS total_amount FROM "T_売上集計" LIMIT 10000
State: FAILED
StateChangeReason: HIVE_METASTORE_ERROR: Unsupported Federation Resource - Invalid table or column names. (Service: AWSGlue; Status Code: 400; Error Code: ValidationException; Request ID: 9802675a-8170-4267-aaf3-290f087afa14; Proxy: null)
Contributing code:
packages/context-manager/src/coa_serve/tier2/nl_to_sql/sql_generator.py L137-145 — the Athena dialect rules tell the model about Trino functions and date literals but say nothing about quoting identifiers, so quoting is left to chance.
Discovery (packages/sources/src/coa_sources/database/…) accepts every table name the JDBC driver returns and never checks it against what Athena federation can address; the unusable name is only discovered at query time.
Playground UI: nl_to_sql_execute_failed / sql_firewall_parse_error fall through to the SPARQL/Ontop path and the final answer is the LLM's "no information in context" — the Athena/Glue error text never reaches the user.
Fix (proposal)
Detect at scan time: flag tables/columns whose identifiers Athena federation cannot address (non-ASCII, #, other reserved characters) with a visible warning on the table row, and exclude them from the queryable surface (or document the limitation) instead of failing silently later.
Quote identifiers deterministically in the SQL post-processing step (the firewall already parses the SQL with sqlglot; re-emitting with identify=True would quote every identifier) rather than relying on the model.
Surface the error: when every strategy fails, show the underlying engine error (or at least "query generated but rejected by Athena: …") instead of the generic no-context text.
Context
Reported by a customer evaluating v0.2.2 on ap-northeast-1 with a Snowflake source ("Playground cannot read Snowflake table data: AthenaQueryError … HIVE_METASTORE_ERROR: Unsupported Federation Resource - Invalid table or column names"). Related: #194 (the same names break the table detail page and per-table Approve).
Additional Information / References
Control case (ASCII table name, same path, succeeds):
Quoted Japanese identifier — Athena rejected it (record above) but the UI shows a generic no-context answer:
Description
A Snowflake table whose name contains Japanese characters or
#scans, approves (via Approve source) and induces fine, but any Playground question that targets it fails. Depending on how the LLM quotes the identifier, the failure happens at three different places — none of which is surfaced to the user. Playground always answers with a generic "the provided context does not contain information about …", so the user cannot tell that a query was generated and rejected.Environment
42b5c6b(tagv0.2.2).sql_generator.py/sql_firewall.py/ the discovery path are unchanged one265573(tagv0.3.1=main).coadevds_*catalog)Step to reproduce
SALES.ORDERS,SALES."T_売上集計"(ID, "対象年月", AMOUNT)andSALES."売上#2024"("集計ID", "合計金額")SELECT COUNT(*) … FROM ORDERS, AthenaSUCCEEDED) — control caseA root cause
Same root, three failure points:
Athena query-execution record for the third case:
Contributing code:
packages/context-manager/src/coa_serve/tier2/nl_to_sql/sql_generator.pyL137-145 — the Athena dialect rules tell the model about Trino functions and date literals but say nothing about quoting identifiers, so quoting is left to chance.packages/sources/src/coa_sources/database/…) accepts every table name the JDBC driver returns and never checks it against what Athena federation can address; the unusable name is only discovered at query time.nl_to_sql_execute_failed/sql_firewall_parse_errorfall through to the SPARQL/Ontop path and the final answer is the LLM's "no information in context" — the Athena/Glue error text never reaches the user.Fix (proposal)
#, other reserved characters) with a visible warning on the table row, and exclude them from the queryable surface (or document the limitation) instead of failing silently later.identify=Truewould quote every identifier) rather than relying on the model.Context
Reported by a customer evaluating v0.2.2 on ap-northeast-1 with a Snowflake source ("Playground cannot read Snowflake table data: AthenaQueryError … HIVE_METASTORE_ERROR: Unsupported Federation Resource - Invalid table or column names"). Related: #194 (the same names break the table detail page and per-table Approve).
Additional Information / References
Control case (ASCII table name, same path, succeeds):
Quoted Japanese identifier — Athena rejected it (record above) but the UI shows a generic no-context answer: