Commit 42570b8
fix(tools/bigquery): keep the provider error classification in bigquery-execute-sql (#3738)
## What
Fixes #3716. On the actual query run, `bigquery-execute-sql` wrapped
every provider failure in a blanket `NewClientServerError("error running
sql", 500, err)`, so a BigQuery 403 from an impersonated service account
missing `dataViewer` surfaced as HTTP 500 and connectors showed an
opaque bad-gateway instead of anything recoverable. The dry-run path in
the same tool already routed through `util.ProcessGcpError`, which made
the two stages inconsistent with each other.
The actual-run error path now goes through `util.ProcessGcpError` too,
the same classification the other GCP tools use (bigtable, firestore,
datalineage, and this tool's dry run): 401/403 keep their status with
the provider cause attached, and everything else becomes a readable
`AgentError` so the model sees the real message (invalid SQL, missing
table) instead of a generic 500.
## How
One-line swap at the `RunSQL` error site, plus
`TestInvokeRunSqlErrorClassification`: a 403 from the provider must come
back as `ClientServerError` with code 403 and the Access Denied cause
visible, and a 400 must come back as an `AgentError` with the cause
visible. Existing tests (`TestInvokeDatasetRestrictions` and the rest of
the package) still pass.
## Verification
- `go test ./internal/tools/bigquery/bigqueryexecutesql/` - all pass,
including the two new classification subtests
- `go vet ./internal/tools/bigquery/bigqueryexecutesql/` - clean
---------
Co-authored-by: Yuan Teoh <45984206+Yuan325@users.noreply.github.com>1 parent 1f77f83 commit 42570b8
1 file changed
Lines changed: 1 addition & 1 deletion
Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
237 | 237 | | |
238 | 238 | | |
239 | 239 | | |
240 | | - | |
| 240 | + | |
241 | 241 | | |
242 | 242 | | |
243 | 243 | | |
| |||
0 commit comments