SCRUM-1159-adapters: get_dialect raises on an unrecognized connector - #329
Merged
Conversation
marcociav-exmergo
approved these changes
Aug 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes : #319
The issue's proposal assumes
explore queryparses agent SQL without the connector's dialect, so a hyphen reads as subtraction under a generic/DuckDB parse. That's not what's happening here:explore queryalready resolvesdialect get_dialect(connector)and threads it into everysqlglotcall in the query firewall, and has done so since very early in the project, before the 1.6.3 the issue was filed against.Verified through the real dispatch path, not just the parser in isolation, against a fake BigQuery client whose project id is itself
hyphenated:
```json {"status": "needs_confirmation", "data": {"command": "explore query", "per_table_bytes"{"myproject.my_dataset.my_table": 31457280.0, ...}, ...}} All three spellings the issue names reach needs_confirmation cleanly:
my-project.my_dataset.my_table, `my-project`.`my_dataset`.`my_table`, and the bare unquoted form copied verbatim from an explore inventory identifier or explore query tables entry.So this PR does not add a dialect= parameter anywhere, that's already there. If the reporter can still reproduce the original failure against a real BigQuery connection, the fix would be something else, most likely a connector-name mismatch (see below), and I'd want their exact command and .dex/config.yml connector value to find it.
What fixed :
One real gap: get_dialect() in adapters/init.py silently returned "duckdb" for any connector name it didn't recognize. That's exactly this failure mode waiting to happen — .dex/config.yml's connector field is a plain string with no enum validation, so a typo or an alias drift would silently parse every statement in the wrong dialect and produce this exact confusing error (a policy-refusal shape pointing at what looks like a SQL parser).
Before: