chore(tidb-stmt-cache): scrub customer-identifiable references

The original sample documentation and inline comments named the
internal service, recording, message broker tenant, and entity-id
format the regression was first reported against. None of those
identifiers are needed to explain the bug — the failure mode is a
generic property of RoundRobinPartition routing across record/replay
sessions. Replace them with neutral phrasing.

Behavioural changes: none. Only docs, comments, and the example
curl payloads are touched.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Author: khareyash05

tidb-stmt-cache/README.md

@@ -8,9 +8,9 @@ against TiDB and Apache Pulsar in a single app:
 | `GET /api/kv/{v}` and `GET /api/kv/insert-select/{v}` | MySQL Connector/J prepared-statement cache + HikariCP LIFO pool → orphan `COM_STMT_EXECUTE` matcher path |
 | `POST /events/patch` | Hibernate INSERT + Pulsar `SEND` on a **partitioned** topic with default `RoundRobinPartitionRouter` → the partition-routing replay regression |
 
-Both flows share the same `HikariDataSource` bean (Flipkart's actual shape:
-`autoCommit=false`, `prepStmtCacheSize=500`, `prepStmtCacheSqlLimit=2048`,
-JPA `provider_disables_autocommit=true`).
+Both flows share the same `HikariDataSource` bean shape that drives both
+regressions: `autoCommit=false`, `prepStmtCacheSize=500`,
+`prepStmtCacheSqlLimit=2048`, JPA `provider_disables_autocommit=true`.
 
 ## Why the Pulsar partitioned topic matters
 
@@ -41,7 +41,7 @@ no recorded mock matches the live topic and replay fails with
 │   └── 30-app.yaml             carries keploy.io/record-session=true for the webhook
 ├── pom.xml
 └── src/main/java/com/example/tidbstmtcache/
-    ├── DataSourceConfig.java   Flipkart-shape HikariCP bean
+    ├── DataSourceConfig.java   HikariCP bean (autoCommit=false, …)
     ├── EventsController.java   POST /events/patch — JPA save + Pulsar send
     ├── EventEntity.java        JPA entity for the `events` table
     ├── EventRepository.java
@@ -68,10 +68,10 @@ APP_PID=$!
 curl -s -X POST http://localhost:8080/events/patch \
   -H 'Content-Type: application/json' \
   -d '{
-    "entity_id": "FMPP4037630682",
+    "entity_id": "ENTITY-1001",
     "event_name": "delivered",
     "event_timestamp": "2026-05-23T17:07:22+05:30",
-    "task_orchestrator": "FSD"
+    "task_orchestrator": "ORCH-A"
   }'
 # Expect: {"message":"Event patched"}
 
@@ -84,7 +84,7 @@ diff `bin/pulsar-admin topics partitioned-stats persistent://public/default/even
 output — partition message counts will land on different partitions
 each cold start.
 
-## Full path — k8s-proxy auto-replay (matches Flipkart prod flow)
+## Full path — k8s-proxy auto-replay
 
 The k8s-proxy controller watches the namespace for pods carrying
 `keploy.io/record-session=true` and injects the keploy-agent sidecar.
@@ -147,7 +147,7 @@ PF_PID=$!
 for i in $(seq 1 5); do
   curl -s -X POST http://localhost:8080/events/patch \
     -H 'Content-Type: application/json' \
-    -d "{\"entity_id\":\"FMPP$i\",\"event_name\":\"delivered\",\"event_timestamp\":\"2026-05-23T17:07:22+05:30\",\"task_orchestrator\":\"FSD\"}"
+    -d "{\"entity_id\":\"ENTITY-$i\",\"event_name\":\"delivered\",\"event_timestamp\":\"2026-05-23T17:07:22+05:30\",\"task_orchestrator\":\"ORCH-A\"}"
 done
 
 kill $PF_PID
@@ -191,19 +191,23 @@ kubectl -n tidb-pulsar-replay logs deploy/tidb-pulsar-app -c keploy-agent \
   `…events`, same payload), the synthetic `SEND_RECEIPT` is returned,
   the app returns HTTP 200, the testcase passes.
 
-## Reproducing the Flipkart symptom exactly
-
-The Strowger recording in `Strowger Playgro Global Shipment (1)/testset/`
-matches this sample structurally — the `POST /events/patch` body, the
-HikariCP shape, and the partitioned Pulsar topic. To run the customer's
-mocks against this app:
-
-1. Replace `k8s/30-app.yaml`'s `PULSAR_TOPIC` env with the customer's
-   topic name (`persistent://toss-relayer/gsm-relayers-prod/toss_EKL-E2E-ORCHESTRATOR_gsm_ns`).
-2. Use the customer's `mocks.yaml` instead of a fresh recording.
-3. Run step 6 with the customer's test-set ID.
-
-Without the fix you should see the same `payload-aware mock mismatch
-for SEND (topic=…partition-7)` log line the customer reported. With the
-fix you should see the `SEND` resolve against the customer's
-`partition-5` mock and the testcase pass.
+## Replaying an existing recording
+
+If you already have a `mocks.yaml` and a `tests/` directory captured
+against a structurally similar Pulsar producer (partitioned topic, JPA
+`INSERT` before the SEND, HTTP 200 response), this sample can serve as
+the replay target:
+
+1. Override `k8s/30-app.yaml`'s `PULSAR_TOPIC` env to match the topic
+   name in your recorded mocks (`persistent://<tenant>/<namespace>/<topic>`).
+2. Load the existing `mocks.yaml` into the test-set storage backend the
+   k8s-proxy install is configured for, instead of running a fresh
+   recording.
+3. Trigger the replay job with that test-set ID.
+
+Without the matcher fix in `keploy/enterprise`, a replay where the live
+producer round-robins to a different partition than the recording will
+log `payload-aware mock mismatch for SEND (topic=…partition-<N>)` and
+the testcase fails. With the fix, the SEND resolves against the
+recorded mock for `…partition-<M>` (same base topic, same payload) and
+the testcase passes.

tidb-stmt-cache/docker-compose.yml

@@ -17,9 +17,9 @@
 # reproduce because there is only one partition to route to.
 #
 # Pin: TiDB v8.5.x is the LTS line current at the time this sample was
-# added. Pulsar 4.0.3 matches the broker version typically deployed in
-# Flipkart's Strowger environment (Pulsar Server 3.x client compatibility
-# is preserved through the 4.x line).
+# added. Pulsar 4.0.3 matches the broker version the regression was
+# originally observed against (Pulsar Server 3.x client compatibility is
+# preserved through the 4.x line).
 services:
   tidb:
     image: pingcap/tidb:v8.5.6

tidb-stmt-cache/pom.xml

@@ -20,11 +20,11 @@
     <properties>
         <java.version>17</java.version>
         <!--
-            Pulsar 3.1.x is the Java client line the Flipkart recording was
-            captured against (see CONNECT mocks: clientVersion=Pulsar-Java-v3.1.1
-            in the Strowger mocks.yaml). Keeping the same major.minor here
-            means the wire-format the recorder sees in CI matches what
-            keploy/enterprise has been hardened against.
+            Pulsar 3.1.x is the Java client line the regression was first
+            captured against (CONNECT mocks show clientVersion=Pulsar-Java-v3.1.1).
+            Keeping the same major.minor here means the wire-format the
+            recorder sees in CI matches what keploy/enterprise has been
+            hardened against.
         -->
         <pulsar.client.version>3.1.1</pulsar.client.version>
     </properties>
@@ -39,8 +39,8 @@
             <artifactId>spring-boot-starter-jdbc</artifactId>
         </dependency>
         <!--
-            JPA + Hibernate are added for the Pulsar/TiDB Flipkart scenario:
-            the production datasource bean we are replicating (autoCommit=false,
+            JPA + Hibernate are added for the Pulsar/TiDB scenario: the
+            datasource bean we are replicating (autoCommit=false,
             spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true)
             only behaves correctly when the JPA EntityManager owns the
             transactional boundary. JdbcTemplate alone won't reproduce the
@@ -68,9 +68,9 @@
             MessageRoutingMode.RoundRobinPartition (Pulsar's default) against
             a topic pre-created with 8 partitions. The starting-partition
             cursor is randomised per producer instance, so the partition a
-            given SEND lands on at record time will differ from replay time —
-            which is exactly the regression keploy/enterprise's baseTopic()
-            change handles.
+            given SEND lands on at record time will differ from replay time
+            — which is exactly the regression keploy/enterprise's baseTopic()
+            matcher loosening handles.
         -->
         <dependency>
             <groupId>org.apache.pulsar</groupId>

tidb-stmt-cache/src/main/java/com/example/tidbstmtcache/DataSourceConfig.java

@@ -9,9 +9,8 @@
 import org.springframework.jdbc.core.JdbcTemplate;
 
 /**
- * HikariCP pool against TiDB :4000 with the same bean shape the Flipkart
- * Global-Shipment-Master service uses in production. Two distinct keploy
- * regressions are exercised by this single sample:
+ * HikariCP pool against TiDB :4000. Two distinct keploy regressions are
+ * exercised by this single sample:
  *
  *  - Orphan COM_STMT_EXECUTE (TiDB prepared-statement cache): driven by
  *    useServerPrepStmts + cachePrepStmts + prepStmtCacheSize on the

tidb-stmt-cache/src/main/java/com/example/tidbstmtcache/EventEntity.java

@@ -10,12 +10,11 @@
 import java.time.Instant;
 
 /**
- * Mirrors the Flipkart Global-Shipment-Master event row that the
- * /events/patch endpoint persists before fanning the event out to a
- * partitioned Pulsar topic. The exact column types are deliberately
- * boring — we are not validating Hibernate type mapping here, only
- * that an INSERT + COMMIT goes through MySQL Connector/J in a way the
- * keploy MySQL parser already covers.
+ * Event row that the /events/patch endpoint persists before fanning the
+ * event out to a partitioned Pulsar topic. The exact column types are
+ * deliberately boring — we are not validating Hibernate type mapping
+ * here, only that an INSERT + COMMIT goes through MySQL Connector/J in
+ * a way the keploy MySQL parser already covers.
  */
 @Entity
 @Table(name = "events")

tidb-stmt-cache/src/main/java/com/example/tidbstmtcache/EventsController.java

@@ -14,12 +14,10 @@
 import java.util.Map;
 
 /**
- * Mirrors the Flipkart Global-Shipment-Master /events/patch endpoint:
- * persists an event row through Hibernate (TiDB) and fans it out to a
- * partitioned Pulsar topic. The request/response shapes match the
- * Strowger recording (test post-events-patch-1.yaml) so a recording
- * captured against this sample produces mocks structurally identical
- * to the customer's.
+ * POST /events/patch — persists an event row through Hibernate (TiDB)
+ * and fans it out to a partitioned Pulsar topic. The request/response
+ * shapes are intentionally generic so any recording captured against
+ * this sample can be replayed with the keploy enterprise agent.
  *
  * Why a synchronous .send() rather than sendAsync(): we want the
  * record-time mock for SEND_RECEIPT and the in-transaction COMMIT to

tidb-stmt-cache/src/main/java/com/example/tidbstmtcache/PulsarConfig.java

@@ -24,10 +24,10 @@
  *
  * Why we do NOT pin a single partition (e.g. SinglePartition + fixed
  * messageKey): pinning would mask the bug, which is the whole reason
- * this sample exists. The point is to reproduce the Flipkart routing
- * mismatch end-to-end so the matcher loosening in
- * keploy/enterprise (baseTopic in pulsar/replayer/replayer.go) can be
- * verified against a real Java producer.
+ * this sample exists. The point is to reproduce the routing mismatch
+ * end-to-end so the matcher loosening in keploy/enterprise (baseTopic
+ * in pulsar/replayer/replayer.go) can be verified against a real Java
+ * producer.
  *
  * Why we accept a topic that may not yet exist on broker startup:
  * docker-compose's pulsar-init container runs `pulsar-admin topics

tidb-stmt-cache/src/main/resources/application.properties

@@ -1,6 +1,6 @@
 server.port=8080
 
-# --- TiDB DataSource (Flipkart-shape) ---
+# --- TiDB DataSource ---
 # TiDB :4000 speaks the MySQL wire protocol, so the MySQL Connector/J 8.x
 # driver works as-is. JDBC URL parameters that matter:
 #