Same @tool decorator wiring bug as #702 (PostgreSQL + MySQL, fixed in #703 and #704), now for Azure SQL. All 5 Azure SQL diagnostic tools silently fail with TypeError: missing 2 required positional arguments: 'server' and 'database' on every agent invocation, because the @tool(...) decorator is missing the is_available and extract_params callbacks.
The broken tools (5 total)
get_azure_sql_current_queries
get_azure_sql_resource_stats
get_azure_sql_server_status
get_azure_sql_slow_queries
get_azure_sql_wait_stats
Root cause
Identical to #702. The @tool(...) decorator on each tool omits is_available and extract_params, so the execution layer in app/nodes/investigate/execution/execute_actions.py:49-50 calls action.run(**{}) — and each tool raises TypeError because server and database are required positional parameters.
The MariaDB tool family at app/integrations/mariadb.py:160-176 has this wired up correctly; the PostgreSQL and MySQL helpers added in #703 and #704 mirrored that pattern. Azure SQL is the third and last of the database tool families sharing the same omission.
Evidence
During the end-to-end audit (make test-rds-synthetic on Gemini 2.5-flash, after #703 and #704 landed), the agent opportunistically invoked Azure SQL tools on RDS PostgreSQL scenarios, producing 92 Azure SQL TypeError failures across the 15 scenarios:
| Tool |
Failures |
get_azure_sql_resource_stats |
38 |
get_azure_sql_current_queries |
34 |
get_azure_sql_server_status |
14 |
get_azure_sql_wait_stats |
6 |
After applying the same wiring pattern used in #703 and #704, those drop to 0. The tools correctly report unavailable when no Azure SQL integration is configured, and the agent stops attempting them on unrelated scenarios.
Proposed fix
Mirror the PostgreSQL/MySQL pattern:
- Add
azure_sql_is_available(sources) and azure_sql_extract_params(sources) to app/integrations/azure_sql.py.
- Wire both into all 5
@tool(...) decorators.
Azure SQL integration resolves credentials internally via resolve_azure_sql_config (same design as PG/MySQL), so extract_params only surfaces the three identifying params: server, database, port. Credentials (username, password, driver, encrypt) stay out of tool signatures and are never seen by the LLM.
I'll submit the PR.
Same
@tooldecorator wiring bug as #702 (PostgreSQL + MySQL, fixed in #703 and #704), now for Azure SQL. All 5 Azure SQL diagnostic tools silently fail withTypeError: missing 2 required positional arguments: 'server' and 'database'on every agent invocation, because the@tool(...)decorator is missing theis_availableandextract_paramscallbacks.The broken tools (5 total)
get_azure_sql_current_queriesget_azure_sql_resource_statsget_azure_sql_server_statusget_azure_sql_slow_queriesget_azure_sql_wait_statsRoot cause
Identical to #702. The
@tool(...)decorator on each tool omitsis_availableandextract_params, so the execution layer inapp/nodes/investigate/execution/execute_actions.py:49-50callsaction.run(**{})— and each tool raisesTypeErrorbecauseserveranddatabaseare required positional parameters.The MariaDB tool family at
app/integrations/mariadb.py:160-176has this wired up correctly; the PostgreSQL and MySQL helpers added in #703 and #704 mirrored that pattern. Azure SQL is the third and last of the database tool families sharing the same omission.Evidence
During the end-to-end audit (
make test-rds-syntheticon Gemini 2.5-flash, after #703 and #704 landed), the agent opportunistically invoked Azure SQL tools on RDS PostgreSQL scenarios, producing 92 Azure SQL TypeError failures across the 15 scenarios:get_azure_sql_resource_statsget_azure_sql_current_queriesget_azure_sql_server_statusget_azure_sql_wait_statsAfter applying the same wiring pattern used in #703 and #704, those drop to 0. The tools correctly report unavailable when no Azure SQL integration is configured, and the agent stops attempting them on unrelated scenarios.
Proposed fix
Mirror the PostgreSQL/MySQL pattern:
azure_sql_is_available(sources)andazure_sql_extract_params(sources)toapp/integrations/azure_sql.py.@tool(...)decorators.Azure SQL integration resolves credentials internally via
resolve_azure_sql_config(same design as PG/MySQL), soextract_paramsonly surfaces the three identifying params:server,database,port. Credentials (username, password, driver, encrypt) stay out of tool signatures and are never seen by the LLM.I'll submit the PR.