Logan already answered this somewhat but I thought I'd elaborate. During replay we sandbox the entire replaying browser and trap all external IO requests using custom handlers which feed in the original recorded response for that IO request.

Replay does this at the system API level, catching network IO, disk IO, IPC, and any other system interaction done by the recorded browser.

Async dependencies are a tough nut to crack. The main query of importance there seems to be "when was this currently executing code first added to the scheduler". Time travel debugging gives us the infrastructure to answer that question in a single click (and transitively the entire chain back to the initial program execution).

However we haven't implemented specific support for these use cases yet. Our initial public beta feature set is "reversible-execution in debugging", "print statements that work in the past", and "cloud collaboration on debugging through shared discussions on individual replays". I'm oversimplifying but that's the gist.

We'll be prioritizing features to implement and user feedback is of course critical in directing that effort. Features for async debugging, more frameworks support, network monitoring, more runtimes and execution environments, time-travel watchpoints on variables and objects, and different domains such as CI-integration (having replays automatically made for CI test runs) and serverside (easily recording and replaying backend code - starting with nodejs).

The current MVP is pretty breathtaking, and there's a ton that can be done on top of it going forward, and we're excited to deliver more :)

It's definitely a well-considered approach. I don't have to care about the framework that's been used or set up a custom proxy to capture and replay / simulate API actions, you're literally recording system-level calls and that would be extremely valuable for replaying those annoying edge-case race conditions that seem nigh-impossible to track down without significant effort at replicating exact steps and timings.

I mentioned in my other comment about Windows support, but even better if you could do something like browserstack, where I could just direct users to a URL where in the backend you guys are running the replay browser, but from their perspective they're just "using the website", that would be a killer feature. "Here, go to this URL and make the bug happen again, as soon as it happens click the little bug icon" - wouldn't have to convince an IT department to allow custom software on their COE, I could foot the bill and pass it on in my invoices so don't need to convince their accounting to approve licensing, etc, and you wouldn't need to compile OS-specific clients...

Anyway I digress, really cool stuff and thanks for expanding a bit on how it works, taking something so low-level as syscalls and wrapping it up in a user-friendly interface is no mean feat - good luck!

It's definitely possible to abstract away HTTP requests for debug purposes; Cypress is one example, which makes a snapshot of the DOM and a log of what happened for every event, and allows the user to stub out HTTP requests. Redux's time traveling debugger omitted HTTP entirely, instead only logging changes in the state.

Cheers for the heads up on cypress, not sure how I've missed it but I've added to my reading list and I'll be doing a deep dive. I'm using redux on my current side project and loving being able to scrub through state changes.

My angle on this thread is that I don't have much control over the frontend frameworks and usually when I land in an enterprise integration job a lot of the broader architecture is already in place - longer term I can have some influence but generally debugging involves numerous stakeholders. A tool like replay seems useful because most testers / users are reporting issues from their direct experience using the frontend, and being able to record and scrub through their interactions would be a massive timesaver, in lieu of setting up custom testing frameworks etc.

I get what you're saying though, and I'll definitely check out cypress, just wanted to add some context.

Once a recording is made, you can jump around in it as much as you like. The network requests will only be made during the initial recording process as they would normally, and when debugging it will all be pulling the request/response data from the recording itself rather than querying the network.

That's a big selling point for me, props to the engineering team for accommodating this, I work mainly on integrations and the trickier bug reports are weird edge cases that involve a lot of getting specific descriptions of what happened and replicating it manually on a sandbox so as not to impact API calls, getting on the phone to talk through exactly what they're doing, asking for screenshots via email, clarifying conflicting understanding of in-house terminology etc. You know the story.

Being able to get them to record the exact process and scrub through it at my leisure without having to worry about hammering APIs would be a massive timesaver, replication is about 90% of the time taken to fix a bug, while the fixes themselves are usually trivial. Not having to worry about accidentally replaying a bugged-out API call is a huge plus.

In my case the major hurdle I can foresee is the majority of my enterprise-level clients use Windows and a brief look at the website says currently there's only Mac / Linux support for the replay browser. What's the timeline on Windows support?

The only other thing I can think may be an issue is that the recordings are cloud-based and a lot of the clients I deal with are finnicky about exfiltration and governance, and would be a lot more comfortable self-hosting where possible. Is that possible or on the roadmap?

This looks like a super useful tool to add to the toolbelt for sure, I would love to have all my clients using something like this to report issues. Nice work all!

(Replay engineer): re: Windows, we have an alpha build out now, with a wider beta release coming later this year.

re: on-prem, it's definitely something we plan to support, and something we have engineered in to the infrastructure. If you're interested email hi@replay.io, we'd love to talk more.

> What's the timeline on Windows support?

Work on Windows support in ongoing now and we're hoping to have at least an initial beta Windows release some time in the next month or two ideally, though it certainly depends on if anything unexpected comes up.