test-zeus-ai/testzeus-hercules

Describe the bug execute_select_query_sql_async parameterizes the query argument correctly, but the optional schema_name argument is not. It gets inserted straight into SQL with an f-string and executed unparameterized. File: testzeus_hercules/core/tools/sql_calls.py, lines 122-126 if schema_name: if engine.dialect.name == "postgresql": await connection.execute(text(f"SET search_path TO {schema_name}")) elif engine.dialect.name in ["mysql", "mariadb"]: await connection.execute(text(f"USE {schema_name}")) The docstring says parameterized queries prevent SQL injection, but that only covers the query argument, not schema_name. To Reproduce Call execute_select_cte_query_sql with a normal query and params, but pass a schema_name containing SQL syntax instead of a plain identifier. The injected content runs as part of the SET/USE statement instead of being treated as data. Expected behavior schema_name should be validated as a plain identifier or safely quoted befo

Describe the bug In some real browser-driven runs, the browser/helper side appears to finish with a meaningful terminal result, but Hercules still fails the testcase because the final result is not parsed into a stable structured output. We observed this with final helper outputs such as: plain text summaries PASS / FAIL style summaries messages containing ##TERMINATE TASK## empty strings None returned from nested chat / helper handoff When this happens, the final testcase may collapse into a vague failure such as “no browser execution result”, even though the browser flow itself already reached a meaningful business conclusion. To Reproduce Steps to reproduce the behavior: Run a browser-driven Hercules testcase that uses nested helper / planner interaction. Let the browser helper finish with a plain-text terminal summary instead of strict JSON, or let the nested handoff produce None / empty output. Observe that the browser-side flow may have already completed a meaningful state