ym0506 opened a new issue, #39783: URL: https://github.com/apache/shardingsphere/issues/39783
## Question I maintain RouteContract, a test-only execution-contract library pinned to ShardingSphere-JDBC 5.5.3. I would like to clarify the supported boundary for an external `SQLExecutionHook` provider: 1. Is classpath registration through `META-INF/services/org.apache.shardingsphere.infra.executor.sql.hook.SQLExecutionHook` intended for external test providers? May a provider rely on a fresh instance per physical execution attempt and the same instance receiving `start` and the normal-success terminal, allowing object-local correlation? Or are these internal implementation details? 2. What compatibility expectations should a version-pinned observer have when upgrading ShardingSphere? If another documented extension point is preferred, which one? ### Reproduction and scope [Standalone runnable probe, pinned revision](https://gist.github.com/ym0506/3d03a9d5d158c52a6a2a1848605f779b/a5b99236810f44ded981b6f340a4623345ef8fd8): Java 17, exact ShardingSphere 5.5.3, disposable MySQL containers, synchronous non-batch `PreparedStatement` reads. No RouteContract dependency, Java agent, or patched upstream classes. After one unobserved warm-up, two equality reads and one fan-out read return the same complete synthetic row. Four start/success pairs occur on four distinct used provider objects, with no reuse or unmatched terminal. The observer ignores hook arguments. Three JUnit tests pass: one native MySQL test and two manually invoked recorder controls. A second run from the portable bundle produces the same result; both runs are my own verification. The README and POM state the exact dependencies and limitations. This agrees with the 5.5.3 implementation in [JDBCExecutorCallback](https://github.com/apache/shardingsphere/blob/8d35894433416ef249ebb6ea21f8a8749648e9b6/infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/execute/engine/driver/jdbc/JDBCExecutorCallback.java#L78-L104), [SPISQLExecutionHook](https://github.com/apache/shardingsphere/blob/8d35894433416ef249ebb6ea21f8a8749648e9b6/infra/executor/src/main/java/org/apache/shardingsphere/infra/executor/sql/hook/SPISQLExecutionHook.java#L29-L45), and [RegisteredShardingSphereSPI](https://github.com/apache/shardingsphere/blob/8d35894433416ef249ebb6ea21f8a8749648e9b6/infra/spi/src/main/java/org/apache/shardingsphere/infra/spi/RegisteredShardingSphereSPI.java#L58-L68). Passing tests do not establish a supported contract; that is what I am asking about. I searched the documentation and open/closed issues, including #26323 and the former SPI-document removal in #27596, but could not find an explicit answer. Exceptional terminal delivery in #39763 is separate and excluded here, as are batches, forced callback overlap, and arbitrary asynchronous application work. Codex materially assisted the investigation, reproducer, and write-up. Thank you for guidance on the intended boundary. -- 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]
