* feat: add Java dynamic dedup sample

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* docs: add Java dedup replay command

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* feat: mirror Go dedup traffic sample

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* ci: harden Java dedup Docker sample

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix: share Java dedup sockets in restricted Docker

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix: bind Java dedup socket directory in Docker

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test: add Java dedup replay fixtures

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix: prebuild Java dedup Docker image

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(java-dedup): drop JaCoCo TCP server requirement

- Update Dockerfile entrypoint to load jacocoagent.jar without
  output=tcpserver, address, or port options. The Java SDK now reads
  coverage in-process via JaCoCo's runtime API.
- Rewrite README to cover dedup mode for native, Docker, and
  restricted Docker without --pass-through-ports.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* docs(java-dedup): focus README on dedup-mode replay

- Trim the README to only cover running the sample in dedup mode for
  native, Docker, and restricted Docker.
- Drop generic build/recording sections; the sample is replay-only
  and CI does not record.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(java-dedup): hardcode docker-compose container_name

- Replaced the ${JAVA_DEDUP_CONTAINER_NAME:-dedup-java} substitution with the literal "dedup-java".
- Keploy's compose parser does not interpolate ${VAR:-default}, so --container-name "dedup-java" failed to match the literal placeholder during `keploy test -c "docker compose up"`.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

---------

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

Point the Java dynamic dedup sample at the published keploy-sdk 2.0.0 artifact instead of requiring a locally installed SDK snapshot.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* feat: attach Java dedup agent in sample

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test: require checked-in dedup fixtures

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test: reduce java dedup fixtures

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test: include dropwizard docker build artifacts

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test: align dropwizard distroless runtime user

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* chore: use released java dedup agent

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* docs: use Java dedup agent 2.0.2

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* ci: remove java dedup sample workflows

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* docs: bump Java dedup agent example to 2.0.6

2.0.6 is the latest io.keploy:keploy-sdk on Maven Central; older
example pins (2.0.2) are kept evergreen so copy-paste works without
landing on a stale release.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): allow shaded jar through .dockerignore

The pom sets <finalName>dropwizard-dedup</finalName>, so `mvn package`
produces target/dropwizard-dedup.jar. The allowlist had the stale
`dropwizard-dedup-0.0.1-SNAPSHOT.jar` filename, which means target/*
was excluding the real jar from the Docker build context. BuildKit
then died with "failed to compute cache key: ... target/dropwizard-dedup.jar:
not found" the moment Dockerfile (and Dockerfile.distroless) tried
to COPY it. Verified locally that all three Dockerfiles (Dockerfile,
Dockerfile.classpath, Dockerfile.distroless) build cleanly after
this fix.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test(dropwizard-dedup): expand fixtures to 200 tests across 4 sets

The previous Dropwizard dedup contract was 16 tests in a single set
with both EXPECTED_DUPLICATES=any and EXPECTED_RETAINED_TESTS=any —
it only verified "something happened", not that dedup picked the
right tests. Spring's contract is 400 / 4 sets / pinned dup+retain
counts, which is what actually catches dedup regressions.

Brings Dropwizard up to the same shape:
- 200 tests split 50/50/50/50 across test-set-0..test-set-3.
- Hits every resource path: /healthz, /catalog (+ {sku} + 404 path),
  /search (term × sort), /files/{path}, /headers (X-Tenant +
  X-Request-Id), /platform/{routes,content/html,events}, /orders
  (POST + GET + PUT + DELETE), with varied params so coverage
  signatures differ enough for dedup to be meaningful.
- Adds run_random_200.sh — same shape as java-dedup/run_random_1000.sh
  — so future re-records are reproducible.

Fixtures captured by replaying each request against the live
dropwizard sample and writing real responses; YAML schema matches
the existing keploy-recorded format exactly.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): match keploy record YAML format exactly

Previous regen was missing three fields the canonical
keploy-record fixtures carry. Added them so the docker mode
replays cleanly:

- spec.assertions.noise.header.Vary: [] — tomcat/jersey emit
  Vary: Accept-Encoding which differs across runtime contexts.
- spec.app_port: 8080 — used by the docker replay path to map
  host port -> container port. Without it the docker leg of
  java-dedup-docker on enterprise PR #1959 failed (linux passes
  because it reads the URL directly from spec.req.url).
- top-level `curl: |` block — informational, but tooling and
  human readers expect it next to each fixture.

200 fixtures regenerated against the same dropwizard endpoints,
all 4 sets x 50 tests intact.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): drop empty mocks.yaml files

Previous regen wrote a placeholder `# empty mocks` mocks.yaml in
each test set; the java-dedup sample doesn't ship one, so neither
should this. Empty mocks aren't harmful but the asymmetry is noise.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): match Spring fixture format for docker replay

The 200 dropwizard fixtures were captured with extra response
headers (Vary, Content-Length) and the 127.0.0.1:8080 host that
Python's http.client emits. The Spring sample's keploy-record
fixtures only carry Content-Type + Date in the response and use
localhost:8080. Linux replay was lenient enough to ignore the
extras, but the docker leg compared them strictly against the
eBPF-intercepted bridge response and failed across all 200 tests.

Aligns the dropwizard fixture format to Spring's:
- Capture only Content-Type + Date in resp.header.
- Drop header.Vary noise entry (no longer needed, header isn't captured).
- Use localhost:8080 in URLs and Host headers (matches Spring).

200 fixtures regenerated against the same dropwizard endpoint set;
4 sets of 50 unchanged.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): noise Content-Length, restore full header capture

Previous attempt stripped Vary + Content-Length from the captured
response header set to look like Spring's keploy-record output —
that broke linux replay too because keploy strict-compares the set
of response headers, not just values: dropwizard's Jetty actually
emits Vary + Content-Length on the wire, so a fixture that omits
them is "missing" a header from the live response and fails the
match across all 200 tests on both linux and docker.

Restores full header capture (Date, Content-Type, Vary, Content-
Length) and adds `header.Content-Length: []` to noise on top of
Date and Vary. That keeps the header set equal between fixture and
live response while letting docker-mode framing (chunked vs explicit
Content-Length) ignore the value drift that originally broke docker.

Reverts the `127.0.0.1` -> `localhost` host swap from the previous
attempt as well; it was unrelated to the docker failure (keploy
sends the recorded Host header verbatim) and only added churn.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): split 200 fixtures into 8 sets of 25

Root cause for the docker java-dedup failure (`expected 200 covered
tests, found 134` from common.sh assertion 419-420):

The keploy-v3 sidecar that reads /tmp/coverage_data.sock and writes
dedupData.yaml inside the container has a timer-based flush. Each
test set's runtime needs to fit inside one flush window for all the
coverage entries to land in the file before keploy enterprise pulls
it ("Successfully synced dedupData.yaml from container").

- Spring (java-dedup): 100 tests/set runs in ~11 s at ~3-10 ms/test
  (Tomcat is fast, JaCoCo footprint is small) — fits cleanly.
- Dropwizard at 50 tests/set was running ~14 s at ~150-280 ms/test
  (Jetty is heavier) — flushes after the first ~33 tests and the
  remaining 17 stay in the sidecar buffer until container teardown.

Splitting the same 200 fixtures into 8 sets x 25 keeps each
keploy test --dedup invocation under the flush window:
  25 tests * ~280 ms = ~7 s per set << flush window.

The fixture content is identical to before — just redistributed.
The sidecar flush bug is on enterprise side; this is the
samples-side workaround until that lands.

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): collapse fixtures into 1 test set of 200

The keploy-v3 sidecar's async write to dedupData.yaml has a
~1.5 s settle window between the last per-test publish and when
keploy enterprise pulls the file. Whatever publishes happen in
that window aren't on disk yet — so each "Successfully synced
dedupData.yaml from container" call drops the trailing ~3 tests.

Going 4x50 -> 8x25 cut the loss from 66 -> 24 (3 per sync x 8 syncs).
Going 1x200 means just one sync, so the trailing-edge loss is
~3 total instead of ~24 total.

Same 200 fixtures, same coverage variety, just merged into a
single test-set-0 directory. Pairs with the matching enterprise
woodpecker bump (TEST_SETS=1, TESTS_PER_SET=200).

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* fix(dropwizard-dedup): scope Docker coverage to app classes

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* feat(java-dedup): add simple Java smoke sample

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

* test(java-dedup): add simple sample dedup artifacts

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

---------

Signed-off-by: Asish Kumar <officialasishkumar@gmail.com>

… gate (keploy#134)

* feat(restheart-mongo): keploy compat lane sample (scaffold)

Mirrors the doccano-django sample shape: the sample owns
orchestration (compose / bootstrap / traffic / coverage), keploy
CI lanes consume it as a thin wrapper.

This is a SCAFFOLD — the full traffic loop driven by the existing
keploy/enterprise lane (`compat_trigger_record_traffic` in
.ci/scripts/restheart-linux.sh, ~600 lines covering CRUD on
/<db>/<coll> + GraphQL + files + ACL + users + bulk + aggregations)
needs to be ported into flow.sh::restheart_record_traffic in a
follow-up. The current loop is deliberately minimal (CRUD on a
seed collection) which is enough to prove the sample boots
end-to-end without keploy.

Layout:
  Dockerfile             — pin to softinstigate/restheart:9.2.1
  docker-compose.yml     — mongo:7 + restheart:9.2.1, env-driven
  flow.sh                — bootstrap | record-traffic | coverage | list-routes
  keploy.yml.template    — globalNoise for _etag/_oid/lastModified/Date
  README.md              — handoff + status notes
Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* feat(restheart-mongo): port full RESTHeart REST surface

Replace the minimal record-traffic stub with the complete loop that
the keploy compat lane needs to gate. flow.sh::restheart_record_traffic
now drives the full RESTHeart 9.x surface end-to-end against bare
RESTHeart, and restheart_list_routes enumerates every (method, route)
tuple it fires so coverage stays in lockstep.

Covered surfaces:
- CRUD on /<db>/<coll> + /<db>/<coll>/<docid> (HAL, _size, _meta,
  _indexes, ETag conditional flow, writeMode insert/update/upsert,
  $-operator PATCH variety)
- Aggregations via _meta.aggrs with avars variable interpolation
  (scalars / arrays / nested / missing / malformed)
- Bulk writes (POST array body, filter PATCH, filter DELETE,
  larger 25-doc batches, mixed valid/invalid)
- GraphQL apps (gql-apps registration, query / mutation / fragment /
  alias / multi-op, BSON scalar coercion on outputs and inputs,
  introspection, error paths)
- Files / GridFS (.files buckets, multipart upload, binary download
  with Range requests, metadata fetch, delete)
- ACL rules (predicate evaluator across method / path-prefix /
  qparams-* / bson-request-* / equals[%U,...] / in[%h,...]) plus
  the mongo permission interceptors (readFilter, writeFilter,
  projectResponse, mergeRequest, filterOperatorsBlacklist,
  propertiesBlacklist, allowBulk*)
- Users (/users) with the userPwdHasher bcrypt interceptor; reader /
  writer roles authenticating via Basic + Bearer; wrong-password deny
- Sessions / multi-doc transactions (/_sessions/<id>/_txns/<txnid>)
  with commit and abort branches
- Auth services (/token form grants, JWT, Auth-Token, Digest,
  OAuth metadata under /.well-known/oauth-*)
- Diagnostics (/ping, /metrics in json/prometheus/openmetrics, per-db
  and per-coll, /health/db, OPTIONS preflight, gzip request encoding,
  Accept-Encoding negotiation)
- MongoMountResolver (multiple databases, encoded collection names,
  root /_size and /_meta, trailing-slash and double-slash variants)

restheart_bootstrap now PUTs every collection record-traffic touches.
README.md describes the sample as a complete keploy compat lane
sample and lists every surface it exercises.

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* ci(restheart-mongo): add per-sample coverage gate workflow

Adds .github/workflows/restheart-mongo.yml plus the helper
.github/workflows/scripts/run-and-measure.sh, modeled on the
doccano-django sample's coverage gate.

* paths-scoped trigger: pull_request and push-to-main both filter
  on `restheart-mongo/**` and `.github/workflows/restheart-mongo.yml`,
  so changes to other samples in this repo do not trigger this
  workflow (and vice versa).
* Three jobs: build-coverage (PR HEAD), release-coverage (PR base
  with first-PR bootstrap escape hatch), and coverage-gate that
  fails the PR if coverage drops more than COVERAGE_THRESHOLD
  percentage points (default 1.0pp, override via repo variable
  RESTHEART_COVERAGE_THRESHOLD).
* Helper script brings the sample up via its own
  docker-compose.yml, waits for the RESTHeart listener (treating
  both 200 and 401 as ready since `/` requires auth), runs
  flow.sh bootstrap → record-traffic → coverage, and emits the
  parsed percentage onto $GITHUB_OUTPUT for the gate job.
* Isolated from the enterprise lane: the enterprise PR pipeline
  (.woodpecker/restheart-linux.yml) calls `flow.sh coverage` only
  informationally and does not gate on it. The gate lives only
  here, on the sample repo, so coverage regressions surface on
  PRs that touch this sample without coupling enterprise CI to
  the route table.

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* ci(restheart-mongo): dump container logs on app wait timeout

build-coverage on PR keploy#134 hung 8 min when restheart never bound
on port 8080 (last_code=000). The helper script silently looped
through both the wait and flow.sh bootstrap timers, then the gate
job aborted without surfacing why restheart didn't start. Adding
an explicit fail-fast + docker logs dump after the 240s wait so a
future failure surfaces the restheart Java traceback (or the
mongo connection error, or whatever else).

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* feat(restheart-mongo): real Java line coverage via JaCoCo overlay

Replaces the prior API-route-surface "coverage" (counting fired
routes / curated route table) with actual JaCoCo line coverage
of the RESTHeart 9.x JVM under traffic.

Architecture:
  - `Dockerfile.coverage` is a multi-stage build: stage 1 (alpine)
    fetches JaCoCo 0.8.13 (jacocoagent.jar + jacococli.jar), stage
    2 layers them into the upstream restheart image (which is
    distroless — no shell, no curl, so jars must be pulled in a
    builder stage and COPY'd over).
  - `docker-compose.coverage.yml` is an OVERLAY: applied via `-f
    docker-compose.yml -f docker-compose.coverage.yml`. It sets
    JAVA_TOOL_OPTIONS=-javaagent:.../jacocoagent.jar=output=tcpserver,...
    so JaCoCo attaches at JVM start and listens on port 6300.
    The base `Dockerfile` and `docker-compose.yml` are untouched,
    so keploy/integrations and keploy/enterprise CI lanes consume
    the base compose and pay zero JaCoCo cost (the agent rewrites
    bytecode at class-load, adding ~5-10% per-call overhead that
    would slow record/replay).
  - `flow.sh::restheart_report_coverage` shells into a one-off
    coverage container to dump execution data via JaCoCo TCP and
    render an XML report against /opt/restheart/restheart.jar.
    When called against the base image (no overlay) it prints
    "INFO: ... uninstrumented" and exits 0 so enterprise lanes'
    `flow.sh coverage || true` informational calls keep working.

Also fixes a pre-existing config bug in the base
docker-compose.yml's RHO env var: the override syntax uses ';'
as a key->value separator (the upstream image's default
RHO uses ';'); the prior YAML-folded version used ',' which
RESTHeart parsed as part of the connection-string value, leading
RESTHeart to ignore the override and bind /http-listener/host to
its localhost default — making the HTTP listener unreachable
from the host port mapping. The base compose now uses ';' AND
explicitly overrides /http-listener/host -> "0.0.0.0".

Removed:
  - `restheart_list_routes` (curated route table denominator).
  - `restheart_list_recorded_routes` (keploy-tests / fired-routes
    reader).
  - The legacy route-surface `restheart_report_coverage` body.
  - `list-routes` subcommand.

Validated locally: helper produced `coverage=52.3` to
GITHUB_OUTPUT against a clean stack (1663/3182 lines covered
in restheart.jar; INSTRUCTION coverage 50.8%).

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* ci(restheart-mongo): drop trailing prose from sticky comment

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* docs(restheart-mongo): document coverage overlay; drop list-routes/FIRED_ROUTES refs

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

* fix(restheart-mongo): pin JWT key + correct globalNoise format for deterministic replay

Two record/replay determinism fixes the full keploy/enterprise compat
matrix needs to go green:

1) RHO `/jwtConfigProvider/key` pinned to a fixed string. Default is
   `key: null` which makes RESTHeart auto-generate a random HS256 secret
   per container start. Recorded JWT bearers carry an HS256 signature
   over the payload using that secret, so a fresh-container replay phase
   rejects the recorded bearer with 401 even though --freezeTime keeps
   `exp` valid. Pinning the secret keeps the bearer signature verifiable
   across record→replay container restarts.

2) keploy.yml.template rewritten to use NESTED globalNoise format
   (`body: { field: [] }`) instead of flat dotted keys (`body.field: []`).
   Keploy's matcher reads `globalNoise.global` as map[section][field]regex
   and treats dotted keys as literal outer keys, never matching the body
   section. Verified by walking pkg/matcher/http/match.go and the
   employee-manager sample's commented example. Fields added:
   header.{Date, Content-Length, Auth-Token},
   body.{_etag, _oid, _id, lastModified, client_ip, latencyMs, access_token}.

Validated locally with all three matrix cells (record-stable-replay-pr,
record-pr-replay-pr, record-pr-replay-stable) — each reaches 296/296
PASSED with these two changes plus the lane-side --port and --freezeTime
flags already in keploy/enterprise#1889.

* fix(restheart-mongo): bound JVM heap to prevent OOM on shared CI runners

RESTHeart 9.x's default JVM uses MaxRAMPercentage=25, which on a
typical Woodpecker runner cgroup (~8GB) lands ~2GB heap. With the
keploy/enterprise compat matrix running 3 restheart cells concurrent
alongside parse-server / umami / doccano cells (12 lane-cells total
on one runner), aggregate memory pressure triggers cgroup OOM and
the kernel SIGKILLs lighter processes (bash, curl) mid-bootstrap.

Observed in keploy/enterprise pipeline 3721/26 (record-stable-replay-pr):
RESTHeart came up cleanly (`127.0.0.1:18070 is now reachable`), then
`bash flow.sh bootstrap 240` got SIGKILL'd (exit 137) before any
seed PUTs landed. Same shape across all 3 restheart cells in 3721.

Cap heap at -Xmx512m (start at -Xms128m). Local single-cell
record/replay peaks at ~280MB heap, so 512m is comfortable headroom
without bleeding into neighbours. With the bound, each cell's
footprint stays under ~700MB (heap + native + mongo); 3 restheart
cells fit alongside other lanes on a shared runner.

Validated locally: cell record-pr-replay-pr 296/0 PASSED with the
new JAVA_TOOL_OPTIONS in place. RESTHeart logs confirm
"Picked up JAVA_TOOL_OPTIONS: -Xms128m -Xmx512m ..." at startup.

* fix(restheart-mongo): prefix RESTHEART_ADMIN_AUTH with `Authorization:` at curl call sites

flow.sh's 214 admin-authenticated curl invocations passed the credential
as `-H "$RESTHEART_ADMIN_AUTH"` where RESTHEART_ADMIN_AUTH defaults to
`Basic YWRtaW46c2VjcmV0` (the credential value alone, no header name).
curl renders that as a header value with no name and the request
arrives at RESTHeart with no Authorization header, producing 401.

Effect on the lane:
  - bootstrap's `PUT /<db>/<coll>` seed-collection writes all 401'd
    silently (each is `|| true`'d), so the seed collections were
    NEVER created. record-traffic ran against an empty mongo.
  - record-traffic's 214 admin-authenticated calls all 401'd. The
    recorded testcases are 256 × 401 (out of 296), 25 × 404, and
    only 9 × 200 (the public /ping and OPTIONS preflights).
  - Lane still passed-by-equality because both record and replay
    fail identically (the 401 wire bytes match), but the lane was
    not actually exercising RESTHeart's admin surface.

Fix: change the call site, not the env. `-H "$RESTHEART_ADMIN_AUTH"`
→ `-H "Authorization: $RESTHEART_ADMIN_AUTH"`. The env var stays a
plain credential ("Basic YWRtaW46c2VjcmV0"), the curl line constructs
the full HTTP header. 214 sites swapped via:
  sed -i 's|-H "\$RESTHEART_ADMIN_AUTH"|-H "Authorization: $RESTHEART_ADMIN_AUTH"|g'

Bare-smoke validation (docker compose up + flow.sh bootstrap +
flow.sh record-traffic against vanilla restheart 9.2.1):

  before:  256 × 401   25 × 404    9 × 200
  after:   110 × 200   59 × 201   49 × 404   33 × 405   25 × 204
            16 × 401   11 × 400    8 × 403    4 × 409    3 × 500

The 16 remaining 401s are the genuinely intentional ones — bogus
JWT bearer probe, malformed Digest, no-auth liveness, and similar.
The 8 × 403 are real ACL-deny coverage that was previously
unreachable behind the universal 401.

* fix(restheart-mongo): noise Etag/Location + disable ACL cache for time-freeze compat

After fixing the Authorization-header-prefix bug in flow.sh (parent
commit), 214 admin-auth calls that previously 401'd now actually
mutate state and reach RESTHeart's normal write/read path. That
exposed two new categories of record/replay divergence the all-401
recording had hidden:

1) Etag header: RESTHeart auto-stamps a hash on every doc / collection
   response. body._etag is already in globalNoise, but the same hash
   also appears as a response header (Etag) — needs to be noised
   separately. Without it, ~85 of 306 tests fail on header.Etag diff.

2) Location header: POST /_sessions returns Location: /_sessions/<uuid>
   where the UUID is server-generated. 2 tests fail without noising.

Both added to keploy.yml.template's globalNoise.global.header.

Separate fix on the compose side: disable mongoAclAuthorizer's cache
(`/mongoAclAuthorizer/cache-enabled->false` via RHO). Default is
cache-enabled with TTL=5_000ms, backed by Caffeine. Caffeine's
internal ticker uses System.nanoTime, which keploy's --freezeTime
LD_PRELOAD shim intercepts — so at replay the wall-clock-bound TTL
never expires. flow.sh's `sleep 6` between `POST /acl` and the
writer-permission test works at record (clock advances, cache reloads
the new rule) but is ineffective at replay (cache stuck on whatever
it loaded first). Result: writer gets 403 at replay despite recorded
200. Disabling the cache makes ACL rules read-through from mongo on
every request — small perf cost in the test environment but
eliminates the time-freeze × cache-TTL interaction.

Local cell record-pr-replay-pr verified 306/306 PASSED with both
fixes in place. Test count went 296 → 306 (10 additional tests
captured because admin operations now mutate state and unlock paths
that previously 404'd).

---------

Signed-off-by: Akash Kumar <meakash7902@gmail.com>

…loy#136)

Adds GET /api/todos/stmt-reset/{id}/{n} which re-executes a server-side
prepared statement n times on the same connection. Combined with the new
JDBC URL flags (useServerPrepStmts, cachePrepStmts, useCursorFetch),
MySQL Connector/J 8.x emits COM_STMT_RESET between re-executions, which
exercises the synthetic-OK fallback path added in keploy/keploy#4217 so
record/replay can be validated.

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Signed-off-by: amaan-bhati <amaanbhati49@gmail.com>

…keploy#135)

Java counterpart of keploy/samples-go/aerospike-tls. A Spring Boot
2.7 service that talks to Aerospike CE on clear-text :3000 via the
aerospike-client-jdk8 driver, recorded and replayed end-to-end with
three bundled scripts that mirror the Go sample's shape one-to-one
(same endpoints, same test-set layout, same scripts).

Endpoints (full parity with the Go sample, 14 total):

  GET    /health
  POST   /put            GET    /get/{key}
  POST   /batch/put      GET    /batch/get
  POST   /scan           POST   /query
  POST   /udf            POST   /cdt/list/append  POST /cdt/map/put
  POST   /touch/{key}    DELETE /key/{key}
  POST   /parallel       POST   /multiclient      POST /freshclient

main.go's concurrency story is ported one-for-one:

  * ClientPolicy.maxConnsPerNode = 256, OpeningConnectionThreshold
    analogue set to 16 so bursts don't outpace upstream connect rate.
  * parallelWrite / parallelRead policies with socketTimeout 10s,
    totalTimeout 30s, maxRetries 10, sleepBetweenRetries 5ms.
  * Two-phase warmup on the main client at startup — sequential
    prelude walks the cluster past cold-start latencies, then a
    parallel fill puts idle connections in the pool before the
    HTTP server accepts the first request.
  * RetryHelper.doOp wraps each PUT and GET in /parallel,
    /multiclient, /freshclient.

scripts/ matches the Go sample's pipeline shape (common.sh +
script-{1,2,3}.sh + same env-var knobs: KEPLOY / PORT / LOG_DIR /
SKIP_DOCKER / SKIP_BUILD). Smoke-tested locally with the dev
keploy binary that carries the Aerospike parser:

  script-1.sh → test-set-0: 8/8 pass
  script-2.sh → test-set-1: 6/6 pass
  script-3.sh → test-set-2: 8/8 pass

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…pared-stmt orphan-EXECUTE (keploy#137)

* feat(mysql-dual-conn): add endpoint to trigger COM_STMT_RESET

Adds GET /api/oms/stmt-reset/{n} which re-executes a server-side prepared
statement n times on the SAME JDBC connection. Updates the OMS JDBC URL
with useServerPrepStmts=true, cachePrepStmts=true, and useCursorFetch=true
so MySQL Connector/J 8.x emits COM_STMT_RESET between re-executions.

This exercises the COM_STMT_RESET synthetic-OK fallback added in
keploy/keploy#4217 during keploy record/replay against this existing
samples-java CI app, avoiding the need to wire a brand new sample
(spring-mysql-redis) into keploy's java_linux pipeline. The existing
dual-handshake test path is unchanged — the Camunda pool keeps the
original JDBC URL, and the new endpoint is purely additive.

Signed-off-by: Yash Khare <khareyash05@gmail.com>

* feat(tidb-stmt-cache): add sample exercising prepared-stmt orphan-EXECUTE

Adds a minimal Spring Boot 3 + JdbcTemplate sample that drives MySQL
Connector/J prepared-statement traffic against a single-node TiDB :4000.
The combination useServerPrepStmts=true + cachePrepStmts=true plus
HikariCP pool LIFO causes Connector/J to skip COM_STMT_PREPARE and emit
COM_STMT_EXECUTE only on cache-hit calls -- exercising the orphan-EXECUTE
matching path that keploy/keploy@b2e68adb's param-alone fallback handles.

A companion CI script and matrix entry will land on keploy/keploy in the
same fix branch (fix/mysql-synthetic-prepare-ok-cachePrepStmts) so the
three compat-matrix cells (record_latest_replay_build, etc.) start
exercising this sample once both PRs merge.

The pingcap/tidb:v8.5.6 image runs with --store=unistore to keep boot
time ~5s and avoid PD/TiKV flakiness; schema (the kv table) is bootstrapped
by a CommandLineRunner inside the app so no init.sql is needed.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Yash Khare <khareyash05@gmail.com>

---------

Signed-off-by: Yash Khare <khareyash05@gmail.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

…flags (keploy#139)

Signed-off-by: Yash Khare <khareyash05@gmail.com>

Signed-off-by: amaan-bhati <amaanbhati49@gmail.com>

…int (keploy#143)

Adds GET /api/cross/{v}, which issues two DISTINCT prepared queries with an
identical one-int parameter signature ("SELECT ? AS v" and "SELECT ? + 1000 AS
w") inside a single request. When both PREPAREs predate the record window
(orphaned mocks, expectedQuery==""), this exercises the matcher's
parameter-aware orphaned-EXECUTE path: a param-only match must not serve query
B's row for query A. a must echo v and b must be v+1000.

Consumed by the keploy/keploy java_linux tidb-stmt-cache e2e job.

Signed-off-by: slayerjain <shubhamkjain@outlook.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>