feat(postgres): add v3 mock kinds + yaml envelopes + register integration (#4101) * feat(postgres): add v3 mock kinds + yaml envelopes + register integration Adds the core-side scaffolding for the deterministic Postgres V3 replayer that lands in keploy/integrations. v3 emits five typed mock kinds into the same mocks.yaml stream that v2 already uses so both parsers can coexist — priority ordering at integration-register time decides which handles a given connection. New types on models.MockSpec: - PostgresV3Session — startup snapshot (SSL response, AuthOk, ParameterStatus bundle, BackendKeyData, initial ReadyForQuery) - PostgresV3Catalog — pg_catalog / information_schema snapshot + framework virtual tables (migration state) - PostgresV3Data — per-table seed rows for the replayer's row store (Schema, Table, PrimaryKey, Columns, Rows, Truncated) - PostgresV3Query — one Execute (extended protocol) or one Query (simple protocol) with SQL AST hash, bind values + formats, param OIDs, full response (RowDescription / Rows / CommandComplete / Error), SideEffects (row mutations, sequence emissions, tx transition) - PostgresV3Generator — named generator stream (UUID / sequence / now()) with replay policy PostgresV3NullCell ("\x00NULL\x00") is the sentinel for SQL NULL cells inside Response.Rows — chosen so it cannot collide with base64-encoded cell data (base64 output only contains [A-Za-z0-9+/=], never \x00). Row cells are stored as []string rather than []*string because gob's encodeArray rejects nil slice elements, which broke the agent → CLI mock stream when the first NULL cell appeared. pkg/platform/yaml/mockdb/util.go grows five new encoder + decoder cases + their envelope structs so the round-trip works under both the yaml and gob mock formats. pkg/platform/coverage/java/java.go bumps the default JaCoCo agent path from 0.8.8 to 0.8.13. 0.8.8 rejects Java 21 class files with IllegalClassFormatException (major version 65); 0.8.13 is the first JaCoCo release that fully supports Java 21 and newer. Users can still override via --jacoco-agent-path. POSTGRES_V3 is added to the integrations.IntegrationType enum so the registry distinguishes v3 from v1/v2. The setup-private-parsers action is updated to add the v3 package to the generated extraparsers.go so the v3 init() runs and registers at priority 110 whenever the integrations module is side-loaded at build time. Refs: keploy/enterprise#1903 Signed-off-by: slayerjain * ci: point integration-ref at v3 feature branch during PR review Temporary override so every workflow that runs go get github.com/keploy/integrations@REF resolves to a commit containing the v3 parser package. The v3 package lives on keploy/integrations#130's feature branch until that PR merges to main; once it does, this default reverts to 'main' in a follow-up. Without this override, golangci-lint / prepare_and_run / release all fail at `go mod tidy` with: module github.com/keploy/integrations@latest found, but does not contain package github.com/keploy/integrations/pkg/postgres/v3 Refs: keploy/enterprise#1903, keploy/integrations#130 Signed-off-by: slayerjain * chore(models): gofmt alignment on PostgresV3 kind block + spec struct tags Signed-off-by: slayerjain * fix(mockdb): attach next_step remediation to PostgresV3 yaml error logs Copilot flagged the 10 `utils.LogError` call sites in the PostgresV3 encode / decode switches as missing the repo-standard structured `next_step` field — the operator-facing guidance every other error path in pkg/agent/proxy / pkg/agent/routes already surfaces. Add two shared constants at the envelope section so both halves of the switch produce identical remediation copy: - nextStepPostgresV3Encode — mock couldn't be serialised; check for non-serialisable values inside the spec, consider re-recording. - nextStepPostgresV3Decode — stored yaml block couldn't be parsed; verify envelope vs mock_kind, check for hand-edits, verify binary version. Each error log now carries mock_name + mock_kind + next_step so an operator can identify the offending record and take the right action without tailing debug traces. Addresses review comments on keploy/keploy#4101. Signed-off-by: slayerjain * fix(postgres-v3): resolve Copilot round-2 review comments Addresses the four fresh Copilot findings from the review on the previous push (keploy/keploy#4101): 1. `pkg/agent/proxy/proxy.go` — add POSTGRES_V3 to the parserType set that gets a TLSUpgrader in record mode. Without this, v3 RecordOutgoing receives a nil upgrader and SSL-enabled Postgres connections can't be recorded at parity with v2/mysql. 2. `pkg/models/mock.go` — switch PostgresV3NullCell from the old "\x00NULL\x00" (rejected by gopkg.in/yaml.v3 as a control character) to "~~KEPLOY_PG_NULL~~". Still collision-free against base64 output ('~' is outside [A-Za-z0-9+/=]) and now survives yaml encode+decode as well as gob. Added a regression test (TestRoundTrip_PostgresV3Query_NullCellSentinel) that pins the round-trip for the NULL-cell path specifically. 3. `.github/actions/setup-private-parsers/action.yaml` — revert the integration-ref default to 'main' so CI on unrelated branches stays reproducible. The Postgres v3 feature branch is now pinned explicitly in the four workflows that need it (golangci-lint.yml + 4 prepare_and_run.yml call sites + release.yml), each with a TEMPORARY comment + pointer to keploy/integrations#130 so the overrides are trivially greppable/removable once that PR merges. 4. `pkg/platform/yaml/mockdb/gob_roundtrip_test.go` — add TestRoundTrip_PostgresV3Session / Catalog / Data / Query / Generator + the dedicated NULL-sentinel test above. These exercise the same InsertMock → Close → readGobMocks → DeepEqual contract the existing HTTP / Redis / Postgres v2 / MySQL / Mongo / DNS tests use, so a future schema drift inside any PostgresV3*Spec fails fast in `go test ./pkg/platform/yaml/mockdb/...` instead of surfacing as a runtime mock-load error. All tests pass locally. Signed-off-by: slayerjain * fix(ci+tests): resolve Copilot round-3 review comments - Workflows: pinned `integration-ref` to the exact commit SHA on the integrations feature branch that contains the Postgres v3 parser, instead of the mutable branch name. Six sites (release.yml, golangci-lint.yml, prepare_and_run.yml x4) now reference ff186820bc9a11700953a3242518aa1445e1cc46, which keeps CI and release builds reproducible even if the branch is renamed or deleted. Each override has an inline TEMPORARY comment pointing at keploy/integrations#130 and describing the cleanup path (drop the key, revert to `main`) once that PR lands. - Added pkg/platform/yaml/mockdb/yaml_roundtrip_postgres_v3_test.go: six new tests covering the full EncodeMock -> yaml.Marshal -> yaml.Unmarshal -> DecodeMocks path for all five PostgresV3 kinds, plus a dedicated NULL-sentinel test. The gob round-trip tests already guarded the binary path; yaml is the default on-disk path for replay, and without these tests the envelope structs could silently drop fields (or fail to parse on control bytes) and no unit test would catch it — the first signal would be a broken replay. The NULL-sentinel test is the first to fail if someone reverts PostgresV3NullCell to a control-byte value that yaml.v3 rejects. Signed-off-by: slayerjain * fix(mockdb): scope PostgresV3 yaml encode next_step to yaml failures The nextStepPostgresV3Encode remediation constant used to name gob-unsafe pointers as a likely cause, but the constant is only referenced from the yaml marshal error path (util.go encode switch). Operators triaging a mocks.yaml write failure would be pointed at the wrong serializer. Rewrote it to name the actual yaml failure modes (embedded NUL bytes / control characters, invalid UTF-8, anchor or alias cycles) and explicitly noted that gob-path issues are tracked separately. The gob round-trip tests already cover the gob side. Signed-off-by: slayerjain * fix(mockdb): reject PostgresV3 mocks with nil typed payload EncodeMock and DecodeMocks used to tolerate a nil kind-specific payload pointer (mock.Spec.PostgresV3Session, .PostgresV3Catalog, .PostgresV3Data, .PostgresV3Query, .PostgresV3Generator) on either side of the yaml cycle. On encode, this silently wrote `: null` to mocks.yaml — a record that looked valid to the loader but made every downstream engine NPE at replay time because they dereference the payload unconditionally. On decode, a hand-edited file with `session: null` (etc.) would load the same dangerous empty mock. Added a typed sentinel errPostgresV3NilPayload and a dedicated nextStepPostgresV3NilPayload remediation string. EncodeMock now checks the payload pointer for each of the five PostgresV3 kinds before calling Encode; DecodeMocks checks it after Decode and before storing into MockSpec. Both paths return the sentinel wrapped with a next_step log field so operators triaging the failure see exactly what to check. Regression: two new table-driven tests pin both directions across all five kinds using errors.Is against the sentinel, so a future revert that loosens the guard fails in go test rather than at replay time. Signed-off-by: slayerjain * ci: bump integration-ref pin to v3 env-gated commit Bumps the six integration-ref overrides from ff186820 to e279bd06 so all keploy CI legs test against the integrations tree with the KEPLOY_POSTGRES_V3 env-var gate. Why this matters: e279bd06 fixes the regression where v3 was hijacking every PG connection at Priority 110 — including those whose only recorded mocks were v2 — causing EOF on startup handshake and failing echo-sql, django-postgres, spring-petclinic-rest and the postgres-fuzzer jobs. v3 now declines MatchType unless the process was started with KEPLOY_POSTGRES_V3=1, so the whole legacy CI suite routes back through v2 exactly as before and v3 engages only when explicitly opted in. This pin will be dropped entirely (back to `main`) once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to 97f49e75 (v3 test-scope fix) Rolls the six integration-ref overrides from e279bd06 to 97f49e75 so CI exercises the integrations tree that plumbs currentTest into Session.CurrentTest. Without the plumbing, every invocation recorded with scope "test:" was dead code at replay time (Session.CurrentTest was never populated, so ScopeMatches rejected them all). Behaviour for v2 recordings is unaffected; the env-gate introduced in e279bd06 still keeps v3 opt-in. Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to 1da68bca (v3 round-9 fixes) Rolls the six integration-ref overrides from 97f49e75 to 1da68bca so keploy CI exercises the integrations tree with: - CurrentTestContextKey as an immutable typed const - canonicalCommandTag's DISCARD ALL vs DISCARD split - lossless DataRow.Values population so SQL NULL stays distinct from literal "NIL"/"NULL" text values and from empty cells v2 behaviour is unchanged; the new DataRow.Values field is purely additive. Env-gate keeps v3 opt-in so the rest of CI continues to route PG through v2. Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * fix(mockdb): guard nil Response in NullCell sentinel test + bump pin Two fixes in one commit so CI picks up both together: - yaml_roundtrip_postgres_v3_test.go: the NULL-sentinel assertion dereferenced .Response.Rows without checking that Response was non-nil first. If a future regression drops the Response field during round-trip, the test would panic at runtime instead of failing with a clear message. Peel the structure one layer at a time with t.Fatal between each step so dependent assertions only run once their prerequisites are verified. - Workflow integration-ref pin bumped from 1da68bca to 1863b9c4 so CI tests against the integrations tree with the round-10 dispatcher fixes (empty simple-Query -> EmptyQueryResponse, emitDescribeResponse going through the SessionManager interface). Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to 858cd3bd (v3 round-11 fixes) Rolls the six integration-ref overrides from 1863b9c4 to 858cd3bd so keploy CI tests against: - CurrentTestFromContext honouring the typed key verbatim (including the empty-string explicit-clear case) - markVolatileFromDivergence no longer conflating NULL-vs-value differences as volatility, so replay keeps NULL-sensitive invocations strictly matched Env-gate stays in place so the rest of CI continues to route PG through v2 unchanged. Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to 17a0168e (v3 round-12 fixes) Rolls the six integration-ref overrides from 858cd3bd to 17a0168e so keploy CI tests against: - Deep-copied bind values at both Bind capture sites (no longer pin the 16 MiB decoded request buffer for the portal lifetime) - Operator-visible log + typed sentinel on reasm overflow (connection enters passthrough-only mode with a clear next_step instead of silently dropping further packets) Env-gate stays in place. Also updated the PR description to describe the pin as "current in the workflow file" rather than quoting a specific SHA, so routine pin bumps during review rounds don't keep triggering the same description-drift review note. Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to dfeb9065 (audit fixes + v3-default flip) Big integrations bump: resolves all P0/P1/P2 items from the principal-engineer v3 audit AND flips v3 to the default Postgres parser. KEPLOY_POSTGRES_V3 is now a KILL-SWITCH (`=0` to force v2), not an opt-in. Every PG-related pipeline in this repo (run_golang_docker echo-sql, run_java_linux spring-petclinic-rest, run_python_linux django-postgres, run_fuzzer_linux postgres-fuzzer) runs in-run record-and-replay with freshly built keploy, so the default flip takes CI onto v3 end-to-end without any extra env-var plumbing — fresh recordings produce v3 mocks, replay consumes v3 mocks, same binary on both sides. Fallback: if v3 breaks a specific job, set `env: KEPLOY_POSTGRES_V3: '0'` at the job level to route PG back through v2 while the fix is developed. Pin will be dropped once keploy/integrations#130 merges. Signed-off-by: slayerjain * ci: bump integration-ref pin to a3de4c60 (v3 wired into omnibus) Rolls to a3de4c60 which adds postgres/v3 to the integrations/pkg/parsers omnibus import list. The prior pin was v3-default-on for logic purposes but silently v2-only at build-time for every integrations Woodpecker pipeline (the omnibus was v2-only). With this pin, integrations CI now actually tests v3 end-to-end, and the record-latest-replay-build / record-build-replay-latest cross-version matrix entries will honestly surface any v3/v2 on-disk incompatibility they were meant to catch. No change needed on the keploy side beyond this pin bump — keploy's setup-private-parsers action already imports postgres/v3 explicitly (and the omnibus import now duplicates it, which is a Go no-op). Signed-off-by: slayerjain * ci: bump integration-ref pin to 645cfa1c (keploy-ref fix + lint) Rolls to 645cfa1c which fixes two build-time failures exposed by pipeline 359 on the integrations side: - .woodpecker/prepare-and-run.yml pinned KEPLOY_REF default to feat/postgres-v3-mock-kinds (this branch) so integrations' Woodpecker can compile v3 against the keploy source that defines models.PostgresV3Session / Catalog / Data / Query / Generator. Previously defaulted to "main" where those symbols don't exist yet, producing "undefined: models.PostgresV3Session" as soon as the omnibus wired v3 in. - 9 golangci-lint issues in the recently-added test files (errcheck on deferred Close, errorlint on err==io.EOF, nilnil, revive var-naming, redundant min polyfill, staticcheck tagged-switch suggestion). Pin will be dropped once both PRs merge. Signed-off-by: slayerjain * ci: bump integration-ref pin to 38d96136 (lib/pq Ping fix + perf) Ships the critical fix for the samples-go/http-postgres Woodpecker pipeline failure (and the listmonk e2e validation's identical failure): v3 replay no longer poisons lib/pq's db.Ping(";") probe with KP003. Also includes five pprof-surfaced perf optimisations (BindMatches map alloc removal, canonicalCommandTag without strings.ToUpper, binary.BigEndian.Append*, RecordedIndex RWMutex, FirstRowDescription helper). Expected CI outcome: record-build-replay-build on http-postgres / ps-cache-postgres now passes end-to-end on v3. The cross-version matrix entries (record-build-replay-latest, record-latest-replay- build) remain expected-fail until both PRs merge and stable binaries ship with v3 support. Signed-off-by: slayerjain * ci: bump integration-ref pin to 8b2e2f27 (Copilot round-N typed-key + volatile order fix) Signed-off-by: slayerjain * ci: bump integration-ref pin to 6ba1153e (listmonk + sap_demo_java regression pipelines) Signed-off-by: slayerjain * feat(models): add PostgresV3QuerySpec.ResultFormats The recorder already captures the client-side Bind packet's ResultFormatCodes into its internal invocation struct, but until now never persisted them onto the PostgresV3Query mock. That's fine for recorded RowDescriptions (the server tells us the Format on the wire directly) but breaks replay for the lib/pq / database/sql INSERT...RETURNING flow: 1. Client Binds with ResultFormatCodes=[1] (binary) 2. Client Describes → no wire RowDescription because server only emits one if the client Describes before Bind 3. Client Executes → server emits 4-byte binary DataRow 4. Recorder captures rows:[AAAAAQ==] but no format codes At replay time, v3's dispatcher synthesizes a RowDescription from the row width (Phase A2, integrations 5e94a84) but has no way to know the bytes are binary — it defaults to Format=0 (text), the driver then tries to text-parse "\x00\x00\x00\x01" as an int, and fails with: sql: Scan error on column index 0, name "?column?": converting driver.Value type []uint8 ("\x00\x00\x00\x01") to a int: invalid syntax This field persistence is the recorder's half of the fix. The integrations repo wires: * recorder/query_capture.go — copy inv.resultFormats into spec * types/contracts.go — add Invocation.ResultFormats * types/index_loader.go — load mock.ResultFormats into inv * dispatcher — consult the first-cohort invocation's ResultFormats when synthesizing RowDescription Semantics: per PG wire, len=0 means "all text", len=1 means "broadcast f[0] to every result column", len=N means per-column. The replayer interprets the same way at Describe time. Regression: `TestYAMLRoundTrip_PostgresV3Query` now round-trips the field. A subsequent integrations-side test pins the dispatcher using it to pick Format=1 for the listmonk `RETURNING id` case. Signed-off-by: slayerjain * ci: bump integration-ref pin to fadc3a4a (Phase A2 binary-format fix) Rolls the six integration-ref overrides from 6ba1153e to fadc3a4a, which ships: - Phase A (fa7b72f): ParameterDescription inference for lib/pq's empty-ParameterOIDs Parse — confirmed working in listmonk round 3 (24 successful inferences, zero "expected 0 arguments" errors) - Phase A2 (5e94a84): RowDescription inference from recorded row width for Execute-only cohorts - Phase A2 binary-format fix (fadc3a4 + keploy 1ecaa96e): plumbs ResultFormats through recorder → PostgresV3QuerySpec → replay so the synthesised RowDescription declares the correct wire Format (binary vs text) per column — the listmonk round-4 bug where "\x00\x00\x00\x01" (binary int4) was text-parsed and failed "invalid syntax" - Strict 100% pipeline gate on listmonk regression tests Signed-off-by: slayerjain * ci: bump integration-ref pin to 479ad383 (Phase A2 real-OID synthesis) Signed-off-by: slayerjain * feat(mockmanager): expose IsTestWindowActive The v3 Postgres parser needs an agent-level signal for whether a test-body window is currently active, to decide which tier (per-test vs session+connection) to route a live query to. MockManager already tracks the window via SetCurrentTestWindow / SetMocksWithWindow but had no public reader for parsers to consult. Add IsTestWindowActive on both the *MockManager implementation and the MockMemDb interface, and update the in-repo test stub. Parsers that partition their index by tier (starting with postgres/v3) can now pick the correct tier deterministically instead of relying on scope strings embedded in individual recordings. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * feat(mockmanager): add strict startup/session/perTest tier accessors Wave 2 gives app-bootstrap queries (Flyway migrations, pool warm-up, ORM metadata boot) their own explicit storage tier instead of silently auto-promoting them into the session pool with a Lifetime mutation. MockManager gains a dedicated startup *TreeDb alongside filtered and unfiltered. SetMocksWithWindow now routes mocks whose ReqTimestampMock predates firstWindowStart into the startup tree without touching their recorder-emitted Lifetime tag. The legacy GetSessionMocks is preserved as a union shim (startup + session) so pre-wave-2 parsers keep working; new strict accessors expose a compile-time-disjoint view: GetStartupMocks() → startup-tier mocks GetSessionScopedMocks() → session + connection-tagged mocks strictly HasFirstTestFired() → sticky signal for "first test window seen" The three accessors are also added to the MockMemDb interface in integrations.go, with GetSessionMocks marked deprecated. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * refactor(models): collapse PostgresV3 mocks to a single discriminated Kind Wave 3 replaces the five per-sub-type PostgresV3 Kinds (Session/Catalog/Data/Query/Generator) with ONE top-level Kind (PostgresV3) carrying a discriminated spec. The sub-type now lives in Spec.PostgresV3.Type, so UI/analytics/search see ONE Kind per protocol rather than five entries for a single logical parser. The five MockSpec pointer fields are replaced by a single *PostgresV3Spec whose Type string names which of its five sub-pointers (Session, Catalog, Data, Query, Generator) is populated. YAML/JSON/BSON tags collapse: mocks.yaml now carries kind: PostgresV3 spec: postgresV3: type: query query: { ... } with no more per-sub-type top-level-in-spec keys. Encode/decode in pkg/platform/yaml/mockdb enforces the invariant at both ends: nil Spec.PostgresV3, unknown Type, or Type-vs-pointer mismatch is a hard reject with the typed errPostgresV3NilPayload sentinel. Extra non-Type sub-pointers that might be set by hand-edits are silently ignored (the Type-matched pointer wins) — documented as a deliberate tolerance so editing stays ergonomic without letting replay NPE on inconsistent records. Gob + YAML round-trip tests exercise every sub-type through the canonical write→read cycle and pin the on-disk wire shape (a TestYAMLRoundTrip_PostgresV3_WireShape check asserts no legacy postgresV3Session/Catalog/Data/Query/Generator keys leak into new output). Nil-payload guards are covered in both encode and decode directions. Clean-break refactor: v3 is unreleased, no backward-compat read path. Pre-wave-3 recordings are rejected by BuildIndex and must be re-recorded. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(mockmanager): route BaseTime-staged per-test mocks into the startup tree Wave-3 review bugs C1 + C3. SetMocksWithWindow had two overlapping defects in its initial-staging path (the Runner/Replayer's start=models.BaseTime seed call fired once before any real test): C1 — the isInitialStaging block appended the per-test input slice into the unfiltered/session tree, polluting the strict session tier with per-test pointers. Tier-aware parsers (v3) that read GetSessionScopedMocks saw bootstrap traffic mixed into their session index. C3 — the startup tree was rebuilt only when the startupInit slice was non-empty OR m.startup was already non-nil. Initial staging produced an empty startupInit and left m.startup == nil, so no rebuild ran. A subsequent test-set whose initial staging also had no bootstrap traffic could then leak the previous run's startup entries; at replay time v3's startupEngine saw an empty GetStartupMocks() right when Flyway migrations, HikariCP pool warm-up, and ORM metadata boot queries were hitting it, every one of those queries missing with KP001. Fix: at initial staging (start == BaseTime) route the full per-test input slice into startupInit — every mock seen before any real test has fired is by definition bootstrap traffic, and the tier they belong in is startup, not per-test and not session. Drop the cross-pollination append that shovelled per-test into unfiltered. Rebuild m.startup UNCONDITIONALLY from startupInit with a fresh empty tree on every SetMocksWithWindow call so no stale pool can survive a new test-set run. When the first real (non-BaseTime) window arrives, the existing pre-filter already re-partitions on req_ts: mocks with req ∈ [start, end] go to filtered, mocks with req < firstWindowStart land in startupInit, and stale previous-test bleed (firstWindowStart <= req < start) continues to drop. The fix leaves that machinery untouched — it only changes the initial-staging seed and the rebuild gating. Tests: TestSetMocksWithWindow_InitialStaging_SeedsStartupTree, TestSetMocksWithWindow_FirstRealWindow_RepartitionsStartup, and TestSetMocksWithWindow_StartupTreeRebuildsOnNewTestSet cover the three fix points; the legacy GetSessionMocks union shim (startup + session) keeps pre-wave-2 parsers seeing bootstrap traffic via the union path. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(replay): keep IsTestWindowActive false during BaseTime staging, include session mocks in startup pool During Runner/Replayer's initial SetMocksWithWindow call with start=models.BaseTime (fired before any test runs to stage bootstrap mocks), two bugs caused tier-aware parsers to miss legitimate startup-phase queries: 1. m.windowStart/windowEnd got written with the BaseTime sentinel, so IsTestWindowActive (which only rejects zero-time) flipped true and the Postgres v3 dispatcher mis-routed bootstrap traffic to the per-test engine. The per-test tree is empty during initial staging (all filtered input was routed to startup by C1/C3 above), so the engine's index held 0 hashes and every bootstrap query — including listmonk install's first `select count(*) from settings` — got `candidates=0` KP001 misses even though the mock was in the startup index. 2. The startupInit slice only included `filtered` (per-test) input, not `unfiltered` (session + connection). Session-tagged mocks that legitimately fire during app bootstrap (listmonk install's `drop type if exists list_type cascade` DDL, tagged `type: config` → LifetimeSession) would route through the session tree alone and remain unreachable until the first test fired. The dispatcher's pre-first-test routing falls through to StartupTransactional with NO fallback — session-tier content is simply invisible during the bootstrap window. Fix: skip the windowStart/windowEnd publish when start == BaseTime, and copy both filtered and unfiltered input into the startup pool during initial staging. Once the first real test fires, SetMocksWithWindow re-partitions normally: the startup tree rebuilds from the firstStart cutoff (so the session-tagged bootstrap mocks drop out of startup and route via session-tier only, as intended). Regression pin: TestIsTestWindowActive_BaseTimeStagingIsInactive asserts (1) the window stays inactive through a BaseTime call, (2) HasFirstTestFired stays false, and (3) a first real-window call flips active on — with a subsequent BaseTime call NOT regressing it back to inactive. TestSetMocksWithWindow_InitialStaging_SeedsStartupTree is updated to assert session mocks land in BOTH startup (for dispatcher pre-first-test routing) and the strict session tree (for post-first- test routing and GetSessionScopedMocks callers). Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(util): extract live template values from response headers (cookie, bearer, generic) At replay time, updateTemplateValuesFromHTTPResp only walked the JSON body when refreshing utils.TemplatizedValues. Listmonk's login 302 carries its fresh Set-Cookie: session=... in the header but has an empty body, so the extractor skipped it entirely and every subsequent test sent the stale record-time session cookie, hitting 403. This commit extends the updater to also walk response headers in sync with the recorded templated response: - Set-Cookie is decomposed per-cookie (matching buildValueIndexV2's Set-Cookie. indexing) and the value slot is updated. - Authorization: Bearer strips the prefix before extracting, to match the record-side first-class case. - Every other header falls back to literal-anchored substring extraction, so "trace-{{.id}}" and "{{.reqId}}" both work. SimulateHTTP's dispatch guard is loosened from "body present" to "body or headers present" so header-only responses (302, 204, ...) still trip the updater. Tests added to pkg/util_test.go cover Set-Cookie, Bearer, generic, literal prefix, and literal no-op header shapes. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(mockmanager): dedup GetSessionMocks union across startup/session overlap N-R1 (round 2) principal-review finding: during Runner/Replayer's initial BaseTime staging, the startup tree is deliberately over-populated with both filtered and unfiltered input so the v3 dispatcher's StartupTransactional engine can serve session-tagged bootstrap DDL (listmonk's DROP TYPE IF EXISTS is the canonical case) before the first test fires. That put the SAME *Mock pointer in both m.startup and m.unfiltered during the pre-first-test window; the legacy GetSessionMocks union shim concatenated both lists and returned the overlapping pointer twice, skewing HitCount / consumedIndex accounting on the Flyway + HikariCP + ORM-boot replay path. Dedup by pointer identity at the union point. Steady-state post- first-test has no overlap so the dedup is a free no-op (zero duplicate hits against the seen-set). Pin with TestGetSessionMocks_DedupsStartupSessionOverlap_DuringInitial Staging; update TestSetMocksWithWindow_InitialStaging_SeedsStartupTree to expect the deduped count (3 instead of 4). Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(mockmanager): atomic WindowSnapshot for coherent HasFirstTestFired+IsTestWindowActive reads C2 (round 2) principal-review finding: IsTestWindowActive reads under windowMu.RLock while HasFirstTestFired reads under swapMu.RLock. Two separate locks = no atomic pair. Callers that read both sequentially (the v3 dispatcher's routeTransactional and types.TierIndex. orderForCurrentState are the hot-path offenders) can observe the forbidden intermediate state Active=true && FirstTestFired=false during a SetCurrentTestWindow / SetMocksWithWindow transition — causing cross-tier misroute between a statement's Parse/Describe and its paired Execute. Introduce models.WindowSnapshot and MockManager.WindowSnapshot() that takes both locks in the declared swapMu → windowMu order and returns a tear-free snapshot. Legacy single-bit accessors are kept and the interface surface gains WindowSnapshot() models.WindowSnapshot so out-of-repo parsers can migrate incrementally. Keep the scope narrow per the review: don't touch SetCurrentTestWindow's firstWindowStart-update contract here (that is deferred round-1 work). Pin with TestWindowSnapshot_CoherentPair — a writer goroutine cycles through BaseTime→real-window transitions while 8 reader goroutines hammer WindowSnapshot(); 40 outer rounds with fresh managers so the first-real-window transition repeats. Assert no snapshot observes the forbidden state. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(replay): tier-aware strictMockWindow — preserve startup + session tiers, drop only stale cross-test per-test The legacy strictMockWindow gate dropped every per-test mock whose req_ts fell outside [currentStart, currentEnd], regardless of whether the mock was recorded BEFORE any test fired (genuine app-bootstrap traffic — listmonk's cacheUsers SELECT, Hibernate init, HikariCP pool warm-up) or in a different test's window (real cross-test bleed). This duplicated the isolation guarantee the Wave 2 three-tier architecture already provides and broke startup-phase replay under the v3 tier-aware dispatcher. Teach the filter to cooperate with MockManager's tier partition: - Lifetime Session / Connection: KEEP unconditionally (span tests). - Lifetime PerTest, in-window: KEEP (per-test tier). - Lifetime PerTest, req < firstWindowStart: KEEP in filtered slice so MockManager.SetMocksWithWindow's startup partition routes it into the dedicated startup tree (GetStartupMocks sees it). - Lifetime PerTest, firstWindowStart <= req < currentStart OR req > currentEnd: DROP — genuine stale cross-test bleed. - Zero timestamps (legacy/incomplete recordings): KEEP defensively. Expose MockManager.FirstTestWindowStart() via the MockMemDb interface and add the optional FirstWindowStartReader extension on coreAgent.Proxy so the service agent can thread the cutoff into the filter without plumbing MockManager internals through service boundaries. When the reader returns zero (no test has fired yet or the proxy doesn't implement it), the filter falls back to the legacy blanket-drop semantics — behaviour is strictly no worse than before for third-party proxies. Legacy matchers consuming GetSessionMocks (the deprecated union shim) observe slightly more startup-tagged mocks in their snapshot, which is tolerable because those matchers were already designed around "promoted to session" lax semantics. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(agent): default GetProxyInfo to v4-mapped IPv6 in non-docker mode Modern Linux distros resolve localhost to ::1 before 127.0.0.1, so apps that open a connection to localhost now hit ::1 first. The BPF cgroup program attached to connect6/bind6/udp6 can only redirect to a non-zero IPv6 address, but GetProxyInfo was publishing [0,0,0,0] for non-docker mode unless cfg.Port was explicitly set. As a result the v6 redirect was a no-op and v6 localhost traffic silently bypassed the proxy. Publish ::ffff:127.0.0.1 by default so the BPF program rewrites ::1 destinations to the v4-mapped proxy address. Gate the behaviour behind a new Agent.EnableIPv6Redirect flag (default true, defaulted in config.New()) so operators can opt back into the legacy all-zero behaviour as a rollback knob. Signed-off-by: slayerjain * fix(agent/proxy): synthesise AAAA with proxy v6 when IPv6 redirect enabled defaultDNSResponse previously returned an empty AAAA answer to avoid steering clients toward an unreachable ::1 in v4-only deployments. Now that GetProxyInfo publishes ::ffff:127.0.0.1 by default for non-docker mode, the proxy IS reachable over ::1 (BPF rewrites v6 destinations to the v4-mapped address), so the empty AAAA answer breaks apps that resolve localhost → ::1 first. Plumb EnableIPv6Redirect from config.Agent onto the Proxy struct and, when set, answer AAAA with the proxy's v6 address (::1 by default, DNSIPv6Addr in docker mode) — mirroring the existing TypeA path. With the flag off, keep the empty AAAA response so legacy v4-only deployments continue to behave as before. Signed-off-by: slayerjain * test(agent): cover non-docker IPv6 redirect default and AAAA synthesis Adds unit tests for both sides of the new EnableIPv6Redirect gate: * pkg/agent/hooks/linux/hooks_test.go (new file) - TestGetProxyInfo_NonDocker_ReturnsNonZeroIPv6 — default-on path publishes ::ffff:127.0.0.1 - TestGetProxyInfo_NonDocker_ZeroWhenDisabled — opt-out preserves the legacy all-zero behaviour - TestGetProxyInfo_NonDocker_CfgPortOverrideStillForcesV6 — cfg.Port override keeps non-zero v6 even with the flag disabled (regression guard for the pre-existing explicit-override branch) * pkg/agent/proxy/dns_test.go (extended) - TestDefaultDNSResponse_AAAA_SynthesisWhenEnabled — returns ::1 AAAA when the flag is on - TestDefaultDNSResponse_AAAA_EmptyWhenDisabled — returns empty AAAA when the flag is off (compatibility fallback) - TestDefaultDNSResponse_A_AlwaysSynthesised — sanity check that the TypeA path is unaffected by the flag The Hooks test constructs a minimal *Hooks without loading BPF programs because GetProxyInfo's non-docker branch only reads opts/cfg. The DNS test uses a minimal *Proxy populated with the fields defaultDNSResponse actually reads. Signed-off-by: slayerjain * fix(agent-ca): detect app's java.home from PID for truststore install Add detectJavaHomeForPID helper that reads /proc//environ for JAVA_HOME and falls back to /proc//exe's symlink target (trimming bin/java to get the JDK root). When the app's JDK differs from PATH's java (SDKMAN, Maven wrapper, absolute-path fat-jar launches), the current installJavaCA imports into the wrong cacerts and the app's TLS stack rejects Keploy's MITM handshake — this detector provides the right target path for the follow-up keytool wiring. The testable core detectJavaHomeFromSources accepts raw environ bytes and an exe-link string so it can be unit-tested without fabricating a /proc structure. Permission failures on /proc//environ return "" silently so callers fall back to the legacy PATH-keytool path. Signed-off-by: slayerjain * fix(agent-ca): plumb app's java.home into keytool truststore install Wire the detector from Commit 1 into the CA install path: - installJavaCAForHome(ctx, logger, caPath, javaHome): new JDK-specific installer. javaHome="" preserves legacy PATH-keytool behaviour; non-empty targets $javaHome/bin/keytool and $javaHome/lib/security/cacerts directly. installJavaCA is kept as a backward-compat thin wrapper (javaHome=""). - SetupCAForApp(ctx, logger, isDocker, appPID, javaHomeOverride): new entry point that plumbs the app PID + CLI override through setupNative → installJavaCAForHome. SetupCA remains a shim for callers that don't track an app PID (e2e harness, Windows path). - resolveAppJavaHome picks the right java.home: --ca-java-home override > /proc auto-detect > "" (PATH fallback). - Proxy now captures opts.Agent.ClientNSPID and opts.Agent.CAJavaHome at construction and passes them to SetupCAForApp in StartProxy. - New --ca-java-home CLI flag on the agent command, bound to SetupOptions.CAJavaHome for operator escape hatch when the exe symlink and JAVA_HOME are both masked. Signed-off-by: slayerjain * test(agent-ca): cover java.home detection and keytool dispatch Unit-test the app-aware Java truststore wiring from Commits 1 and 2: java_detect_test.go exercises detectJavaHomeFromSources (the testable core) against: - JAVA_HOME present in environ (happy path, SDKMAN/Maven wrapper) - JAVA_HOME vs similarly-named vars (MAVEN_JAVA_HOME) — exact-key - Empty JAVA_HOME= falls through to exe-link - /proc//exe fallback with modern + JRE-style layouts - environ wins over exe when both are populated - non-java exe paths refuse to return a spurious java.home - degenerate /bin/java returns empty rather than "/" Plus the thin wrapper detectJavaHomeForPID for pid<=0 and ENOENT tolerance, extractJavaHomeFromEnviron for malformed/whitespaced entries, and resolveAppJavaHome for override/zero-PID precedence. ca_install_java_test.go uses a fake $javaHome/bin/keytool shell script (sentinel-logged argv) to verify: - installJavaCAForHome targets $javaHome/lib/security/cacerts and the javaHome-scoped keytool (the Track C core guarantee) - Missing $javaHome/bin/keytool falls back to PATH keytool and does NOT report the resolved-path as required - installJavaCA(javaHome="") is a silent no-op when PATH has no java (backward-compat preserved) Signed-off-by: slayerjain * perf(proxy/util): remove EOF retry sleep from ReadBytes ReadBytes previously retried a zero-byte io.EOF up to five times with a 100 ms sleep between attempts, contributing up to 500 ms of pure wait per connection close on the record hot path. The retry was leftover scaffolding from a since-fixed bug in which a spurious short EOF could race real data; under current invariants a (0, io.EOF) return is authoritative and no further bytes can arrive. This commit drops the maxEmptyReads constant and the time.Sleep, so EOF now returns immediately with whatever bytes were already read. Non-EOF errors continue to surface unchanged. The parallel ReadRequiredBytes helper still contains the same pattern and is left alone — it is only used from parser-driven paths that are out of scope for this performance track. Benchmark (BenchmarkReadBytesEOF): before: ~401 ms/op after: ~1.4 µs/op Tests added: - TestReadBytes_EOFReturnsImmediately — asserts <10 ms wall time on empty-EOF so the sleep cannot be reintroduced silently. - TestReadBytes_TableDriven — data-then-EOF, short-data, non-EOF error surface correctly. Signed-off-by: slayerjain * perf(proxy): parallelize upstream TLS dial with MITM client handshake On the record-mode HTTP-only path, handleConnection used to run two TLS handshakes serially: 1. MITM client-facing handshake (keploy's generated cert) 2. tls.Dial(upstream) Each is ~1 RTT, so every intercepted TLS connection paid the round trip twice end-to-end. This commit introduces a speculative upstream dial that is kicked off in parallel with the client-facing handshake using the SNI already peeked from the ClientHello. When the per- connection ALPN/config decision is finalized, the dial is either joined (fast path) or abandoned and synchronously redialed (fallback). The optimization is scoped tightly: * Only triggered when isTLS, non-test mode, no CONNECT-tunnel dstConn already present, not the Postgres-SSL preamble path, and no mTLS client-private-key is configured. * Parser-driven paths (Postgres v2/v3, MySQL, gRPC) keep their existing upstream-dial ownership — the speculative dial never fires on those branches, so parsers remain authoritative for their own TLS sequencing. * If mTLS is negotiated after the client handshake, the speculative conn is abandoned (the upstream cfg needs the client cert). * At the join site we redial synchronously when the addr differs from what we speculated, when the caller's ALPN is narrower than what we offered and the server negotiated a protocol the caller doesn't accept. * A defer abandons any still-live speculativeDial on every early return between start and join/abandon so no socket or goroutine leaks on the error paths. Helper type speculativeUpstreamTLS uses a buffered channel + sync.Once to make join() / abandon() race-safe and idempotent, and abandon() detaches a drain goroutine so the hot path doesn't block waiting for a slow cancelled dial to observe its ctx cancellation (the goroutine closes the conn if the dial happened to succeed in the cancel race window). Tests: - TestStartSpeculativeUpstreamTLS_Join_Success / _Abandon_Cleanup / _DialFailure / _ContextCancelDuringDial — cover happy path, idempotent abandon, dial error, and mid-dial cancellation. - TestSpeculativeParallelism — drives a 100 ms upstream handshake delay in parallel with a 100 ms simulated client handshake and asserts the total is closer to max() than sum(). Guards against accidental serialization regressions. - TestNextProtosSubset — unit coverage for the ALPN-subset helper. Race-surface notes (for reviewers): * cancel before drain in abandon() — goroutine still receives the buffered result and closes any live conn. * join uses sync.Once so interleaving with abandon (which is defensively called in the deferred cleanup) is a no-op. * The speculative dial uses NextProtos=[h2, http/1.1] regardless of the caller's eventual preference; the join-site subset check falls back to a fresh dial if the server picked a protocol outside the caller's accepted set. Security invariants preserved: * InsecureSkipVerify matches the existing synchronous dial — the speculative dial does NOT weaken cert verification relative to today's code. * mTLS client cert path is explicitly excluded (speculative conn is abandoned when isMTLS). Signed-off-by: slayerjain * perf(proxy/dns): allow DNS cache in record mode The DNS cache (bounded LRU, 30 s TTL) previously only stored entries in test mode; record-mode lookups short-circuited before the cache Add so every DNS query the recorded app issued went to the upstream resolver again. Many client libraries open one TCP connection per request and each connect triggers a resolve — on workloads with a modest handful of hosts the resolver was hit hundreds of times per recording session. This commit lifts the mode guard so upstream resolutions are cached in both record and test modes. A cache hit short-circuits before resolveUncachedDNSResponse is invoked, which is the only code path that calls recordDNSMock, so cached hits cannot emit a duplicate mock. As a second line of defense recordDNSMock already maintains a 30-minute (name, qtype) dedupe tracker (p.recordedDNSMocks), so even without the cache-hit short-circuit the replayer would still see each query exactly once per session. The 30 s TTL is kept intentionally short: * long enough to amortise the resolver round-trip across a burst of TCP connections from one client library instance; * short enough to pick up DNS record changes that happen during a long recording session (blue/green, rolling deploys) so the captured fixtures reflect current reality. Synthetic/fallback responses (FromUpstream=false) are still never cached — pinning a fallback for 30 s after a transient upstream failure would starve the rest of the session. The decision has been factored into a named helper shouldCacheDNSResponse(mode, resp) so the invariant is explicit at both the call site and a dedicated unit test. Tests: - TestShouldCacheDNSResponse — table-driven coverage of the (mode x FromUpstream) cacheability matrix including MODE_OFF. - TestDNSCacheLifecycle_RecordMode — pin the core invariants using a 100 ms TTL: first Add/Get returns the cached entry, subsequent Get within TTL keeps returning it (so a second resolution / mock emission does NOT happen), third Get after TTL expiry misses. - TestDNSCacheLifecycle_DedupeStillCatchesDuplicates — second line of defense: even if the cache were removed, the per-mock dedupe tracker would still suppress duplicate emissions. Signed-off-by: slayerjain * fix(proxy/util): conditional EOF retry during handshake phase Track D (96df8446) removed the 100ms x 5 EOF retry loop from ReadBytes to eliminate up to 500ms of wall time per connection close on the record hot path. Session B's listmonk Postgres e2e then started halting at replay boot with "error connecting to DB: EOF": the v3 replayer is still finishing its startup-response write when the app issues its first Read on the proxied conn, and the unconditional fast-return propagated a spurious zero-byte EOF to the app before any test ran. This commit restores a bounded retry, but only for the ambiguous case: zero bytes collected in the current ReadBytes call AND an io.EOF result. Budget is HandshakeEOFRetryMax (3) x HandshakeEOFRetrySleep (50ms) = 150ms worst case — ~3x tighter than the pre-Track-D 500ms loop. Mid-stream EOF (len(buffer) > 0: short-data-then-EOF, or any read that already collected bytes) still fast-returns, preserving Track D's perf benefit on the record hot path. Non-EOF errors are unchanged — still authoritative. Tests: - TestReadBytes_EmptyEOFRetriesWithinBudget: asserts the handshake retry fires and stays within the 150ms budget. - TestReadBytes_MidStreamEOFFastReturn: asserts data-then-EOF returns in <10ms (Track D perf preserved). - TestReadBytes_HandshakeRace: regression test that simulates the listmonk replayer race — two spurious EOFs then payload — and proves the bounded retry recovers without tripping the budget ceiling. - TestReadBytes_HappyPathPerf: CI guardrail that 50 happy-path calls finish under 150ms total, so the handshake sleep can never leak into data-present reads. Benchmarks on Ryzen 9950X: BenchmarkReadBytesEOF ~150ms/op (full retry budget) BenchmarkReadBytesHappyPath ~1.9us/op (Track D perf goal) Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * ci: build keploy agent with CGo outside Dockerfile (pg_query_go) Session P pulls in pg_query_go / libpg_query via the integrations module's postgres/v3 package (keploy imports it via extraparsers.go blank imports). pg_query_go links libpg_query through CGo, so every go build path that produces the keploy binary needs CGO_ENABLED=1 and a working gcc. User contract: CGo lives where the binary is BUILT — GHA runners with gcc on PATH — NOT inside the runtime Dockerfile. Per-site changes: - prepare_and_run.yml::build-and-upload (linux/amd64): set CGO_ENABLED=1 on the non-race build explicitly so a cross-compile slipping in fails loud rather than silently producing a non-cgo binary that panics on first pg_query.Parse. ubuntu-latest already ships gcc. - prepare_and_run.yml::build-linux-arm64: CGO_ENABLED=1 explicit on the ubuntu-24.04-arm native runner (aarch64 host toolchain). - prepare_and_run.yml::build-darwin-arm64: MOVED from ubuntu-latest cross-compile to macos-latest native. Linux cannot cross-compile darwin cgo without an osxcross toolchain (a big lift for one build leg). macos-latest GHA runners are Apple-silicon, so the build is native darwin/arm64 with CGO_ENABLED defaulting to 1. - prepare_and_run_integrations.yml::build-and-upload: CGO_ENABLED=1 on the non-race build. build-essential / gcc already installed via apt at job head. - Main Dockerfile: CGO_ENABLED=1 set via ENV so downstream build-args can't accidentally disable it. golang:1.26 (bookworm) ships gcc so no extra apt install is needed. Docstring at the top clarifies this Dockerfile is for external/user-side `docker build .` invocations — CI uses Dockerfile.runtime (COPY-only) per the Session P build-outside-Dockerfile contract. - goreleaser.yaml: CGO_ENABLED=1 on the `keploy` and `keploy-docker` build specs. release.yml still runs goreleaser on macos-latest which can only cross-compile windows (via the existing mingw-w64 override on the keploy-windows leg); linux cross- compile from macOS would need osxcross/zig-cc. TODO comment inline documents the follow-up: split release.yml so each platform leg runs on a native runner before tag releases can publish linux binaries again. Not touched (deliberately): - Dockerfile.runtime — already the COPY pattern Session P wants; no go build inside the container. - tests/e2e/agent-ready-gated-on-ca/Dockerfile, tests/e2e/ca-bundle-merge/Dockerfile.setup — these build e2e-specific test harnesses that do NOT import integrations transitively (verified: their only go.keploy.io imports are pkg/agent/routes and pkg/agent/proxy/tls, neither of which pulls pg_query_go). Their CGO_ENABLED=0 pins stay. - go-test.yaml — already CGO_ENABLED=1 with build-essential. - Windows native cgo build leg (prepare_and_run.yml:: build-windows-amd64) — already runs on self-hosted Windows with MinGW, no change needed. The user's issue #138 concern is satisfied: mingw-w64 cross-compile is NOT used; the Windows binary is built natively. Pre-existing dirty go.mod / go.sum (local-dev scaffolding with replace directive pointing at a local integrations checkout) is intentionally NOT committed — per Session P contract, those are local scaffolding and must stay untracked until a separate upstream-swap commit replaces them. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * ci: split release.yml across native runners for CGo (pg_query_go) Session P (commit f62602b8) flipped CGO_ENABLED=1 on both the `keploy` and `keploy-docker` goreleaser build specs so pg_query_go v6.2.2 / libpg_query links correctly. Session P left an inline TODO in goreleaser.yaml noting that release.yml still drives every platform leg from a single macos-latest runner, which cannot cross-compile: - linux/amd64 + linux/arm64 from macOS without an osxcross/zig-cc toolchain; - darwin/* from linux for the same reason (symmetric); - windows/amd64 from linux via mingw-w64 — pg_query_go issue #138 documents this cross path as unreliable (libpg_query does not upstream a stable mingw-w64 build recipe). Until the split lands, tagging a release produces either a failed build-go job or silent non-cgo binaries that panic on the first pg_query.Parse call. This commit unblocks tag releases by fanning the build across native runners. New job graph: build-linux (matrix: ubuntu-latest amd64, ubuntu-24.04-arm arm64) — native `go build` with CGO_ENABLED=1, produces keploy_linux_.tar.gz for the public release AND a separate keploy-docker binary (SENTRY_DSN_DOCKER ldflag) uploaded under the unchanged release-keploy-linux- name that build-docker already consumes. build-darwin (macos-latest) — Apple silicon runner's clang handles both darwin/amd64 and darwin/arm64 via the universal macOS SDK, so no osxcross. `lipo` fuses them into a universal binary; gon signs and notarizes the fused binary using the same secrets the old job used (Apple certs, team id, app password). Result: keploy_darwin_all.tar.gz, matching the historical archive name in keploy.sh. build-windows (windows-latest) — native cgo via the MinGW-w64 gcc that ships with the hosted runner image. Avoids the pg_query_go #138 cross-compile path entirely. Produces keploy_windows_amd64 (bare binary, matches goreleaser's format_overrides: goos=windows → format=binary contract). release (ubuntu-latest, needs all three) — downloads the per-platform archives and publishes one GitHub release via `gh release create`. Uses --generate-notes for release notes and toggles --prerelease based on the tag suffix (mirrors goreleaser.yaml's prerelease:auto). Keeps --latest=false so mark-latest decides after docker images are signed. build-docker / build-docker-manifest / mark-latest — unchanged graph, except build-docker now `needs: build-linux` instead of the old build-go and mark-latest now needs the new `release` job. The per-arch docker artifact contracts (release-keploy-linux-amd64/arm64) are preserved byte-for-byte so the Dockerfile.runtime COPY-only flow still runs identically. Why not `goreleaser release --skip=build` on the final job: the OSS build cannot merge dist/ trees produced on different runners (split-and-merge is a Pro-only feature). The release block in goreleaser.yaml is small enough (prerelease:auto, mode:replace, draft:false, make_latest:false) that replicating it with `gh release create` is cheaper than shipping the Pro binary into CI. goreleaser.yaml stays in the repo as the canonical ldflags source of truth and for local snapshot builds. Secrets preserved as-is from the old job: GITHUB_TOKEN, SENTRY_DSN_BINARY, SENTRY_DSN_DOCKER, CLIENT_ID_GITHUB_APP, APPLE_DEVELOPER_CERTIFICATE_P12_BASE64, APPLE_DEVELOPER_CERTIFICATE_PASSWORD, APPLE_ACCOUNT_TEAM_ID, APPLE_ACCOUNT_PASSWORD, INTEGRATIONS_REPO_DEPLOY_KEY_PRIVATE. Not touched: goreleaser.yaml's inline TODO comment. It now describes the state pre-split; updating it is a follow-up cleanup, deliberately left for a separate commit so this change is a pure workflow restructure. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * fix(mockmanager): H4 startup-rebuild ID-stamp collision During Runner/Replayer's initial BaseTime staging, the same *models.Mock pointer can appear in both startupInit and unfilteredForTree (the BaseTime branch copies the unfiltered slice into startupInit so the pre-first-test dispatcher sees every bootstrap-reachable mock). The startup loop then stamped mk.TestModeInfo.ID = idx on the shared pointer, and the immediately-following SetUnFilteredMocks re-stamped the same pointer with its own slice index. The shared mock's in-memory .ID thereafter reflected only the unfiltered stamping, desynchronising the startup tree's idIndex from the mock's live state. Not functionally reachable today because the startup tree is read-only for parsers (no UpdateStartupMock / DeleteStartupMock paths exist), but structurally a landmine for any future code that tries to update or delete startup-tier mocks via a key derived from the live pointer. Fix: stamp a local copy of TestModeInfo as the startup tree key rather than mutating the shared pointer. The startup tree stays internally consistent on its own tier-local ID space while the mock's .ID remains free to be re-stamped by SetUnFilteredMocks without corrupting the startup index. SortOrder, which doesn't participate in the collision (it's derived from the recording and stable across re-stampings), is still stamped on the shared mock when missing so all tiers observe a deterministic comparator value. Regression test pins the invariant: a session mock seeded during initial staging ends up in both startup and unfiltered tiers with its .ID reflecting the unfiltered stamp, and GetStartupMocks still surfaces it via the startup tree. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * feat(mockmanager): N1 GetStartupMocksByKind for API symmetry Adds a by-kind accessor on the startup tier to match the existing GetUnFilteredMocksByKind / GetFilteredMocksByKind on the session and per-test tiers. Tier-aware parsers (the out-of-tree Postgres v3 dispatcher is the load-bearing caller) that maintain per-kind indices over the startup pool can now query directly instead of filtering the full GetStartupMocks snapshot client-side. Implementation filters the startup tree walk in-memory rather than maintaining a separate per-kind tree. The startup pool is bounded by app-bootstrap traffic — Flyway migrations, ORM metadata boot, driver- handshake queries, HikariCP pool warm-up — which in practice sits at ~10^2 mocks. The walk-filter is O(N) with a small N and avoids the lock-surface expansion a parallel per-kind index would require. If the pool ever grows to where this is measurable, the remediation is to mirror the per-kind trees the session / per-test tiers maintain. Exposed on the MockMemDb interface so parsers consuming the interface directly (not just the concrete MockManager) can reach it. The sole existing test mock (http/match_test.go) gains a stub returning (nil, nil). Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * feat(models): MockName constants for PostgresV3 kinds (N-R5) Adds MockNamePostgresV3Query / MockNamePostgresV3Session as exported string constants. The integrations-repo recorder currently hardcodes these values as string literals when stamping Mock.Name on recorded PostgresV3 mocks; exposing them on the keploy side lets a follow-up integrations-repo commit migrate the recorder to the shared constants without drifting the spelling. Mock.Name is an identifier that participates in hit-count indexing, dedup, and by-name lookups in MockManager — a typo in the recorder would silently split the pool into two unrelated subsets. No consumer migration in this commit — the integrations side is a separate repo and its migration lands as a separate PR. This is pure surface exposure so the integrations-side change can reference models.MockNamePostgresV3Query / models.MockNamePostgresV3Session instead of the string literals. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * style(http/match_test): gofmt re-align after GetStartupMocksByKind stub The previous commit added a GetStartupMocksByKind method to the test mock in http/match_test.go, which (because it spans multiple lines) changed the column alignment gofmt uses for the adjacent single-line method declarations. Re-apply gofmt so the column widths snap to the new longest line. Pure cosmetic; no behaviour change. Co-Authored-By: Claude Opus 4.7 (1M context) Signed-off-by: slayerjain * ci: repoint integrations SHA after force-push + scope CodeQL MITM cert rule Two independent regressions kept PR #4101 red end-to-end even though the per-job GitHub summary showed a rainbow of success checks: 1. All four `integration-ref:` pins in the workflows (prepare_and_run.yml ×4, release.yml ×3, golangci-lint.yml ×1) targeted integrations commit 479ad383e856. That SHA used to be on `keploy/integrations@feat/postgres-v3-parser` but was dropped by a subsequent force-push (it's now only reachable as a dangling commit via the GitHub API). `go get @` cannot fetch a commit that isn't reachable from any ref, so every Linux/macOS leg and lint bailed with: go: github.com/keploy/integrations@479ad383…: invalid version: unknown revision 479ad383… Meanwhile the self-hosted Windows runner had the old SHA cached at C:\Users\keploy\go\pkg\mod\…@v0.0.0-20260422053554-479ad383e856, so its `go get` step succeeded but the subsequent compile exploded with "undefined: models.PostgresV3Session / …Catalog / …Data / …Query" — the cached code still used the pre-wave-3 per-kind MockSpec fields, which this repo no longer exposes (single discriminated `MockSpec.PostgresV3 *PostgresV3Spec` with `Type` ∈ session|catalog|data|query|generator). Bump all four pins to the current feat/postgres-v3-parser tip (`3d3f2a0fe4e77008e6f84a83225d99f8a6a1b3e0`, reachable from HEAD of that branch), which loads via the wave-3 sin…

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!