mirror of https://github.com/sysown/proxysql
Observed confusion:
- MCP failures like 'Error 100' / 'Error 101' were visible at endpoint level but gave no direct clue whether they came from query-rule blocks or backend execution failures.
- Connection/firewall-style failures also lacked enough target/query context in lower-level logs.
Changes in this commit:
1) Log MCP query-rule block/OK matches with rule id and context
- In Discovery_Schema::evaluate_mcp_query_rules():
- when error_msg rule action is applied, log:
rule_id, tool, target_id, schema, error_msg, query preview.
- when OK_msg rule action is applied, log:
rule_id, tool, target_id, schema, ok_msg.
- This makes it explicit which runtime_mcp_query_rules row produced the returned error.
2) Add detailed backend execution error logs in Query_Tool_Handler
- For MySQL and PostgreSQL execution paths (with and without schema switching), failures now log:
- target_id
- schema (when applicable)
- backend error text
- SQL query text
- Added context for PG search_path failures too.
- This disambiguates rule-block errors from actual backend connectivity/authorization/firewall failures.
Behavioral notes:
- API responses are unchanged (to avoid breaking tests expecting exact messages).
- Logging is now sufficiently descriptive to trace each failure to either:
- a specific MCP rule id/action, or
- a concrete backend execution error.
Validation:
- Recompiled successfully:
- lib/obj/Discovery_Schema.oo
- lib/obj/Query_Tool_Handler.oo
pull/5386/head
parent
8fbd570c79
commit
7e54883ba5
Loading…
Reference in new issue