This series of blog posts explains how Replay works: what happens when a recording is created, how that recording is replayed, and how the replayed program is analyzed to get the information needed to debug it.

First, though, what are we recording? Replay’s devtools are based on a time travel debugger. Unlike a conventional debugger, which can only show a program’s state at the current point in time, a time travel debugger can show that program’s state at all points in time. Saving enough information to be able to do this is tricky. It isn’t efficient enough to record how the state changes over time — in the case of a web browser, even just loading a webpage can perform billions of operations that affect the browser’s state, and keeping track of these will slow things down hugely.

Instead, first recognize that browsers and similar programs are largely deterministic. Given the same inputs (data read from the network, user events like mouse clicks, and so on) the browser will behave in about the same way. If we record those inputs as well as any internal non-determinism which can affect its behavior, then we can run the browser again using that data and it will behave in the exact same way as it did when recording. The state at any point in time can be reconstructed simply by replaying the browser to that point. The browser’s inputs can be recorded with little overhead, and its behavior can be replayed with little post processing needed. Together, these enable a time travel debugger with revolutionary speed and efficiency.

• Recording and Replaying: Describes the basics of recording and deterministically replaying software.
• Effective Determinism: Introduces the concept of effective determinism: there are crucial benefits gained from allowing behavior to vary in certain ways when replaying.
• Inspecting Runtimes: Shows how Replay’s backend and the program being replayed cooperate when handling requests from clients that are inspecting the recording.