A, A, B Is Not the Same Replay as A, B
Why duplicate request observations must preserve their sequence.
Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.
Two requests can have the same method, URL, and body while occupying different positions in an application’s conversation. Deduplicating them can change behavior even when the unique set of responses looks unchanged.
Kalu’s replay engine preserves capture sequence within the relevant request bucket. A sequence of A, A, B is not reduced to A, B merely because the first two observations look the same.
Order is part of the observed protocol
Imagine a synthetic application that polls a resource and receives two pending responses followed by a ready response. Removing one pending observation changes when the application reaches the ready state. Returning the last response forever changes the conversation again.
The current engine treats exhaustion as exhaustion. It does not silently fetch from the live origin or repeat the last distinct response to make the application appear healthy. Ambiguous sequence identities are also not resolved by an arbitrary choice.
Browsing repeatability has a narrower exception
Manual serving can repeat an initial response without advancing only when the bucket’s responses satisfy the supported equality policy for status, body identity, and relevant representation headers. That is a browsing convenience for genuinely repeatable observations.
Qualification does not enable that browsing-only repeat policy. The distinction prevents a convenient manual server behavior from becoming evidence that the original finite sequence was preserved under qualification.
Request identity is more than a path
The matching model includes method, URL and query, and request-body identity under its bounded rules. Different origins that share a path can remain ambiguous. A path-only shortcut should not manufacture certainty about which captured exchange belongs to the request.
This article describes current replay-engine behavior, not support for every network protocol. The implemented request and representation policy remains part of the product boundary.
For an evaluation, use a small sequence where duplicate observations matter. It is more revealing than a page whose assets can all be served interchangeably. A replay system needs to preserve the conversation the application observed, not merely the set of files that happened to cross the network.