feat: add mysql-dual-conn E2E sample app#122
Conversation
Spring Boot app with two HikariCP connection pools using different MySQL credentials and JDBC URL parameters. Tests that Keploy correctly matches HandshakeResponse41 packets during replay when capability flags differ between connections.
There was a problem hiding this comment.
Pull request overview
Adds a new Spring Boot E2E sample app (mysql-dual-conn) intended to reproduce/validate Keploy’s MySQL multi-handshake matching behavior by running two separate HikariCP pools against the same MySQL instance using different credentials and JDBC URL capability flags.
Changes:
- Introduces a new Spring Boot module with two independently configured MySQL
DataSource/JdbcTemplatebeans. - Adds REST endpoints (
/api/query-both,/api/oms,/api/camunda) that execute simple queries to trigger connections from both pools. - Adds local MySQL provisioning via
docker-compose.yml+init.sqland runtime configuration viaapplication.properties.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| mysql-dual-conn/pom.xml | New Maven module definition for the Spring Boot app + JDBC dependencies. |
| mysql-dual-conn/src/main/resources/application.properties | Configures two distinct JDBC URLs/users to force differing handshake capability flags. |
| mysql-dual-conn/src/main/java/com/example/mysqlreplicate/DataSourceConfig.java | Creates and tunes two HikariCP pools and exposes two JdbcTemplate beans. |
| mysql-dual-conn/src/main/java/com/example/mysqlreplicate/QueryController.java | Adds endpoints that query both DBs to trigger the two handshakes. |
| mysql-dual-conn/src/main/java/com/example/mysqlreplicate/MysqlReplicateApplication.java | Spring Boot application entry point. |
| mysql-dual-conn/docker-compose.yml | Provides a local MySQL 8 container with init script mounted. |
| mysql-dual-conn/init.sql | Creates the two databases and users needed for the dual-credential scenario. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| public Map<String, Object> queryBoth() { | ||
| Map<String, Object> result = new HashMap<>(); | ||
|
|
||
| // OMS query — user=omsAppUser, db=myntra_oms | ||
| List<Map<String, Object>> omsResult = omsJdbc.queryForList("SELECT 1 AS oms_check"); | ||
| result.put("oms", omsResult); |
There was a problem hiding this comment.
queryBoth() builds the response with a HashMap, which doesn't guarantee key iteration order. Since these sample apps are used for record/replay style E2E tests, a nondeterministic JSON object key order can introduce flaky response matching. Prefer a deterministic map implementation (e.g., insertion-ordered) for the response payload.
| config.setMaximumPoolSize(maxConns); | ||
| config.setMinimumIdle(2); | ||
| config.setKeepaliveTime(5000); | ||
| config.setIdleTimeout(10000); | ||
| config.setConnectionTimeout(5000); | ||
| config.setValidationTimeout(2000); | ||
| config.setMaxLifetime(7200000); | ||
| config.setLeakDetectionThreshold(2000); |
There was a problem hiding this comment.
The HikariCP pool is configured with very aggressive timing/leak-detection settings (e.g., keepalive/connection/validation timeouts and a 2s leak detection threshold). For CI/E2E usage this can make startup and runs flaky on slower hosts and may generate noisy pool activity/logs unrelated to the handshake scenario being tested. Consider relying on Hikari defaults here, or at least relaxing these values and making them configurable via properties.
| <groupId>com.example</groupId> | ||
| <artifactId>mysql-dual-conn</artifactId> | ||
| <version>0.0.1-SNAPSHOT</version> | ||
| <name>mysql-dual-conn</name> | ||
| <description>E2E test for Keploy MySQL multi-connection handshake matching</description> |
There was a problem hiding this comment.
This new sample module doesn't include a README.md with run instructions (docker compose up, how to run the app, and which endpoints to hit). Other sample apps in this repo include per-module READMEs, and having one here will make the E2E scenario reproducible for contributors and CI debugging.
Summary
omsAppUser/myntra_omsandstagebuster/camunda)useSSL=falsevsuseSSL=false&allowPublicKeyRetrieval=true) cause different MySQL capability flags/api/query-both,/api/oms,/api/camundamysql_dual_connjob in keploy/keploy#3950 to verify Keploy correctly matchesHandshakeResponse41packets during replayTest plan