Mock.Noise is added, but Mock.DeepCopy() currently doesn't copy the Noise slice, so any code that deep-copies mocks (e.g., to avoid races) will silently drop noise patterns and lose obfuscation-aware matching. Update DeepCopy to deep-copy Noise (and include it in the returned Mock).

In findBinaryMatch, treating a single noisy mock buffer as a perfect similarity (mxSim=1.0) can cause this mock to win even if other request buffers are completely different, since matching uses a global max similarity across all buffers. Instead, skip noisy buffers in the similarity calculation (or aggregate similarity across all non-noisy buffers) so noise doesn't force an unconditional best match.

These Info-level logs run for every request match attempt and will likely flood logs in normal operation. Consider downgrading to Debug (or gating behind a verbose flag) to avoid high log volume and performance impact.

The noise-aware ExactBodyMatch uses JSONBodyMatchScore and then treats matched==total as an exact match, but the score only iterates over keys present in the mock JSON. This allows requests with extra non-noisy fields to still be considered an "exact" body match. If this is meant to be exact equality ignoring noisy fields, ensure the comparison also fails on extra request keys (except those corresponding to skipped noisy fields), e.g., by stripping noisy fields from both sides and doing a deep equality check.

Logging a per-mock noise-aware match score at Info inside the match loop can be extremely noisy and expensive at runtime (N mocks per request). Consider changing this to Debug (or only logging the winning mock / when no match is found) to reduce operational overhead.

Hook failure is logged as an error but doesn't provide any actionable next step or context (e.g., which test case failed). Consider including identifiers (test case name/ID, testSetID) and a next-step hint (e.g., "disable custom record hooks" or "check enterprise hook implementation logs").

Hook failure is logged as an error but doesn't provide any actionable next step or context (e.g., which mock failed). Consider including identifiers (mock name/kind, testSetID) and a next-step hint (e.g., "disable custom record hooks" or "check enterprise hook implementation logs").

Hook failure is logged as an error but doesn't provide any actionable next step or context (e.g., which mock failed). Consider including identifiers (mock name/kind, testSetID) and a next-step hint (e.g., "disable custom record hooks" or "check enterprise hook implementation logs").

getCachedRegexp silently drops invalid regex patterns (returns nil) with no surfaced error, which can make "noise" mismatches very hard to diagnose. Consider returning an error (or at least collecting/reporting invalid patterns via a debug log or counter) so misconfigured Mock.Noise patterns are visible to operators.

This Info-level aggregate log is emitted on every JSON-body match pass and may flood logs under load. Consider changing to Debug (or only logging when multiple candidates remain / when matching fails) to keep production logs actionable.

getCachedRegexp logs via log.Printf("WARNING: ...") when a noise regex is invalid. This adds a warning-style log line (and uses the stdlib logger) without a clear next step for users. Consider returning/propagating the compile error to the caller so it can be logged via the existing zap logger with actionable guidance (e.g., which config/mock produced the pattern), or silently ignoring invalid patterns if they’re not user-actionable.

HasExtraNonNoisyKeys doesn’t treat extra elements in request arrays as “extra non-noisy keys”. In the []interface{} case it only compares up to min(len(mv), len(rv)) and then returns false, so a request like [1,2,3] can be considered “exact” against a mock [1,2] (when matched == total). Consider adding a length check (e.g., if len(rv) > len(mv) then return true) so arrays with additional request elements don’t incorrectly pass as exact matches.

Hook error logs (e.g., BeforeTestCaseInsert hook failed) don’t provide any actionable next step for the user, even though recording continues after the failure. Consider including guidance such as how to disable the hook/feature or where to look (enterprise hook implementation) and whether the failure affects recording results, so users know what to do when they see this error.

Hook error logs (e.g., AfterTestCaseInsert hook failed) don’t provide an actionable next step and don’t indicate whether the test case was still recorded successfully. Consider enriching the log message/fields to clarify impact (insert succeeded vs not) and provide guidance on resolving or disabling the hook implementation.

Hook error logs (e.g., AfterMockInsert hook failed) don’t provide an actionable next step and don’t clarify whether the mock insert succeeded (it appears to, since this is in the success branch). Consider adjusting the message/fields to state the insert result and include guidance for fixing or disabling the hook implementation so users can act on the error.

These new Info logs on every successful HTTP mock match (http mock matched) may be very high-volume in normal operation (proxy matching runs per request) and could noticeably increase log noise/cost. Consider downgrading to Debug (or gating behind a verbose flag), keeping Info for only user-actionable lifecycle events.

CI is pinned to a feature branch of the private parsers repo via integration-ref: feat/obfuscation-aware-matching. This can break builds when the branch is force-pushed/deleted and makes CI results less reproducible. Consider pinning to a tag/commit SHA (or omitting integration-ref to use the default) and updating it through a controlled release process.

This second integration-ref: feat/obfuscation-aware-matching occurrence also pins CI to a moving branch for the docker-image build job. Consider using the same pinned tag/SHA approach here as well so both jobs build against an immutable parser revision.

HasExtraNonNoisyKeys treats any request key not in mockKeys as “extra”, but mockKeys is built by excluding keys whose mock value is noisy. This makes common cases like {password: <noisy>} in the mock be considered an extra key in the request (since password is excluded from mockKeys), causing otherwise-valid noise-aware exact matches to be rejected. Consider treating keys as present regardless of noise (only skip value comparisons/recursion for noisy fields), or include noisy keys in the allowed key set while still ignoring their values.

StripNoisyFields uses a nil []interface{} result when all array elements are stripped. encoding/json marshals a nil slice as null, which can change semantics (and similarity scoring) compared to an empty array []. Initializing result with make([]interface{}, 0, len(v)) avoids emitting null for empty arrays.

PerformFuzzyMatch recomputes Levenshtein distance (ComputeDistance) for logging even though findStringMatch already computed distances while selecting the best match. This adds extra O(n*m) work on the hot path purely for debug output. Consider returning the distance from findStringMatch (or computing the percentage only when debug is enabled) to avoid the duplicate computation.

JSONDiffWithNoiseControl now accepts obfuscationNoise, but all in-repo callers pass nil (HTTP matcher, gRPC matcher, schema matcher). As a result, the new obfuscation-aware branch in matchJSONWithNoiseHandlingIndexed is currently unused in this codebase. If the PR intends to make matchers obfuscation-aware, plumb a real NoiseChecker from the relevant source; otherwise consider removing this parameter to avoid dead/untested code paths.

_ = base64.StdEncoding.EncodeToString(reqBuff) is a no-op (result unused) and can be removed. Leaving it in looks like leftover debugging and makes the inner matching loop harder to read.

In findStringMatch, when an exact string match is found (dist == 0), the function currently returns index 0 regardless of which mock string matched. This can select the wrong mock if the exact match occurs at a later index (especially after noise stripping). Return the current idx (and distance 0) instead of hardcoding 0.

PerformFuzzyMatch's binary (Jaccard) loop recomputes request shingles (CreateShingles(reqBuff, k)) for every mock. Since reqBuff and k are constant across iterations, precomputing the request shingles once outside the loop would avoid repeated work and reduce CPU for large bodies / many mocks.

noiseCache is a global map with no eviction/size bound. Since cache keys are the raw regex patterns (likely derived from recorded mocks), long-running processes that load many distinct mocks/patterns can grow this map unbounded and retain memory permanently. Consider bounding the cache (LRU/TTL) or scoping it to a replay/recording session instead of using a process-wide map.

ExactBodyMatch does JSON parsing of the request body inside the per-mock loop (pkg.IsJSON + json.Unmarshal of body each iteration). This is O(#mocks) re-parsing and can become a noticeable hot path when many mocks share the same schema. Parse/validate the request JSON once before the loop and reuse reqData (and an isReqJSON bool) while iterating mocks.

PerformFuzzyMatch now duplicates the Jaccard-similarity loop that already exists in findBinaryMatch, but against mockStrings (noise-stripped). This duplication makes it easier for the two implementations to drift. Consider refactoring so the binary fuzzy match logic lives in one place (e.g., update findBinaryMatch to accept the preprocessed mock bodies / NoiseChecker and call it here).

getCachedRegexp recompiles the same invalid regex pattern on every call because failures aren’t cached (it returns nil immediately). If an invalid pattern appears in Mock.Noise, this can become a repeated compile cost during matching. Consider caching a negative result (e.g., store a sentinel) or filtering/validating patterns once so subsequent checks don’t re-run regexp.Compile.

The doc comment for HasExtraNonNoisyKeys says it excludes keys whose mock value is noisy, but the implementation explicitly treats noisy keys as valid keys for presence checks (and only skips value recursion). Please align the comment and behavior to avoid confusion for future maintainers (either update the comment or adjust the key-handling logic).