# Deja: sites deliberately left un-instrumented

Most of the record/replay work is about choosing where a boundary goes. An equally
load-bearing set of decisions is where a boundary deliberately does **not** go. Those
choices are invisible in the code — an absent boundary looks identical to an oversight —
so they are recorded here, and the call sites carry a one-line pointer back to this file.

Two failure modes motivate every entry below.

**Nesting.** A boundary that wraps other boundaries is substituted as a unit on replay.
Substituting the outer call returns the recorded reply *without executing the body*, so
the inner boundaries never run and their events are silently missing from the replay. An
outer boundary over instrumented inner calls therefore does not add fidelity; it removes it.

**Recording a secret that the seam already handles.** Where non-determinism enters at a
narrow seam, instrumenting the seam records the minimum. Instrumenting the surrounding
computation instead records its output — which may be the very secret the seam was chosen
to keep off disk.

## `crypto_operation` — `hyperswitch_domain_models::type_encryption`

Not a boundary. `crypto_operation` is pure computation over inputs that are all already
deterministic on replay, so it reproduces byte-identically when re-run live. Instrumenting
it would only record non-`serde` metadata that cannot be substituted, forcing a dishonest
verdict exclusion.

The single source of crypto non-determinism — the AEAD nonce — is recorded and replayed at
its own seam (`common_utils::crypto::NonceSequence::new`, a `deja::id` boundary). Given
substituted inputs the rest of the chain is pure:

- the master key is config, identical across record and replay;
- `DecryptLocally` of the merchant key store derives the DEK via `GcmAes256::decode_message`,
  which has no randomness;
- the encrypted ciphertext (DEK and PII) arrives from substituted DB reads;
- the plaintext arrives from the kernel-re-driven request.

Recording the output instead would write the plaintext DEK — the merchant's data key — into
the event log, where recording the seam does not.

> **Open item (tracked, not resolved here).** The last paragraph does not currently hold
> globally: `generate_aes256_key` *is* instrumented (`router::services`), and that is the DEK
> generator used by `db::merchant_key_store`, `db::merchant_connector_account` and `db::events`.
> The plaintext DEK therefore does reach the tape at that seam. Under the full-fidelity capture
> policy this may be intended, but the "keeps it off disk" reasoning above is not a guarantee
> the reader should rely on. Tape protection is a separate, deferred workstream.

## `delete_multiple_keys` — `redis_interface` (fred and redis-rs)

Not a boundary. It is a thin wrapper that maps `delete_key` over each key, and `delete_key`
is already hermetic. An outer boundary would nest: substituting the wrapper on replay
returns the recorded reply without executing, skipping the inner `delete_key` calls and
omitting their recorded `DEL` events. The inner boundaries carry record and replay.

## `perform_locking_action` and `free_lock_action` — `router::core::api_locking`

Not boundaries. Acquiring a lock is a redis SETNX-and-get retry loop
(`set_multiple_keys_if_not_exists_and_get_values`); releasing one is a `delete_key` on the
lock key. Neither is an independent source of non-determinism. Once the redis boundary is
hermetic the lock outcome replays deterministically from the recorded redis reply, so a
separate `deja::lock` boundary would only double-record — and substituting it would skip,
and therefore omit, the inner redis call.