ym0506 opened a new issue, #39763: URL: https://github.com/apache/shardingsphere/issues/39763
## Bug Report ### Which version of ShardingSphere did you use? Master at `bd48f5204c8bbfcb87f7e52fd8d39f8457946520` (5.5.4-SNAPSHOT), checked on 2026-09-08. OpenJDK 17.0.15 and Maven wrapper 3.9.14. ### Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy? The shared `infra/executor` module. The maintained consumer that supplies a sane result is ShardingSphere-Proxy's heterogeneous protocol/storage compatibility path. This is a deterministic unit reproduction; I have not run a live heterogeneous Proxy/database reproduction. ### Expected behavior If the physical `executeSQL` call throws `SQLException`, the started `SQLExecutionHook` receives one `finishFailure` with that exception, including when a compatibility result is returned to the caller. Trunk/worker return handling remains unchanged. ### Actual behavior When protocol and storage types differ and `getSaneResult` returns a value, the hook receives `start` but neither terminal callback. The trunk still receives the sane result, while a worker returns no result. ### Reason analyze The [sane-result return precedes `finishFailure`](https://github.com/apache/shardingsphere/blob/bd48f5204c8bbfcb87f7e52fd8d39f8457946520/infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/execute/engine/driver/jdbc/JDBCExecutorCallback.java#L95-L104). Moving the existing failure notification before the fallback decision preserves the return policy and closes the hook lifecycle. The maintained path is [`ProxyJDBCExecutorCallback.getSaneResult`](https://github.com/apache/shardingsphere/blob/bd48f5204c8bbfcb87f7e52fd8d39f8457946520/proxy/backend/core/src/main/java/org/apache/shardingsphere/proxy/backend/connector/jdbc/executor/callback/ProxyJDBCExecutorCallback.java#L104-L107) → `DialectSaneQueryResultEngine`. This was found while auditing SQLExecutionHook completion for RouteContract; it is not a claim of a failure in RouteContract's supported JDBC/MySQL workload. ### Steps to reproduce / example code The [two-file candidate commit](https://github.com/ym0506/shardingsphere/commit/b13ad32b12ceb92868445c98dcc811dadf39ecc5) includes the regression in `JDBCExecutorCallbackTest`. On the base revision above, apply **only the test-file diff**, leaving production unchanged, and run: ```sh ./mvnw -pl infra/executor -am -DskipITs -Dspotless.skip=true \ -Dtest=JDBCExecutorCallbackTest -Dsurefire.failIfNoSpecifiedTests=false test ``` Both trunk/worker cases first pass the existing return-value assertion, then fail with `VerificationInOrderFailure: Wanted but not invoked: finishFailure(...)`. The test observes the constructed hook, checks the original exception, and checks that no extra hook interaction occurs. With the production change applied, all 3 focused tests and the 196-test executor suite pass. Scoped Spotless/Checkstyle and Apache RAT also pass. ### Related reports I checked open and closed issues/PRs for SQLExecutionHook, getSaneResult, finishFailure and JDBCExecutorCallback. [#18897](https://github.com/apache/shardingsphere/issues/18897) / [#19525](https://github.com/apache/shardingsphere/pull/19525) concern when heterogeneous fallback is attempted; this report concerns its missing hook completion. AI assistance: OpenAI Codex assisted with the investigation, reproduction and candidate patch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
