Show HN: Time travel debugger for web development

Post by missblit » Wed, Sep 15, 2021, 9:32 PM UTC

bhackett wrote: post #154

missblit wrote: post #147

Earlier quoted context omitted.

> Likewise, the raw pointer values don’t have an effect on the behavior of the JavaScript There are actually some cases where raw pointer values can effect user-visible browser behavior indirectly. Notably if the pointer values affect iteration order in an associative data structure which the browser uses in some way that tickles JS differently depending on the order. There are bunches of other bizarre edge cases you…

(Replay employee) Yeah, later in the post ( https://medium.com/replay-io/effective-determinism-54cc91f56... ) we mention needing mitigations to ensure that hashtable iteration is deterministic in cases where it affects how the browser interacts with the JS engine. There are others needed as well to ensure that the browser behaves the same across a large range of websites, my favorite is handling sites that sniff info…

Post by rrdharan » Wed, Sep 15, 2021, 9:43 PM UTC

LeonidBugaev wrote: post #49

For those who are looking to similar tooling in back end space, check - https://undo.io/ (It can also support Golang https://docs.undo.io/GoDelve.html ) - Mozilla RR https://rr-project.org/ - GDB https://www.gnu.org/software/gdb/news/reversible.html Unfortunately, works only in Linux. https://en.wikipedia.org/wiki/Time_travel_debugging

Post by glass_of_water » Wed, Sep 15, 2021, 9:57 PM UTC

bhackett wrote: post #158

glass_of_water wrote: post #150

I read the medium post ( https://medium.com/replay-io/how-replay-works-5c9c29580c58 ), which gives an overview of how Replay works, but there are a few things I still don't understand. 1) How does the step backward functionality work? Do you take snapshots every so often of the Javascript environment? How do you handle destructive assignments? 2) Does Replay record actual syscalls made by the browser, or is it record…

(Replay employee) 1. Rather than having to restore state to the point at the previous step, we can step backwards by replaying a separate process to the point before the step, and looking at the state there (this post talks about how that works: https://medium.com/replay-io/inspecting-runtimes-caeca007a4b... ). Because everything is deterministic it doesn't matter if we step around 10 times and use 10 different proce…

Post by weaksauce » Wed, Sep 15, 2021, 9:59 PM UTC

a_c wrote: post #159

jazzdan wrote: post #111

Earlier quoted context omitted.

(Replay engineer): we basically record all the inputs and outputs to a program. In the example of an HTTP request: when recording we'd record that a request was made, and the response. When replaying, rather than make the HTTP request, we return the response that was recorded. If you're interested you can learn more about how Replay works here: https://medium.com/replay-io/how-replay-works-5c9c29580c58

Thanks for the pointer. Will take some time to digest the content. Have you considered in making a library, so whoever wants a session replay can manually initiate a recording? So you don't have to maintain a browser fork. I am asking without fully understanding the technical detail. Please forgive my ignorance

Post by eurasiantiger » Wed, Sep 15, 2021, 10:06 PM UTC

jazzdan wrote: post #127

donio wrote: post #108

Earlier quoted context omitted.

How will this work on the long run? Will you try to upstream the required changes or will the forks have to be maintained perpetually?

(Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver and could serve as a good starting point.