3 ms·

Mentioned it up thread, but this is _exactly_ what our Replay time-traveling debugger for JS lets you do! We specifically let you add "print statements" to any

Mentioned it up thread, but this is _exactly_ what our Replay time-traveling debugger for JS lets you do! We specifically let you add "print statements" to any line of code from the recorded app, let you toggle them or change conditions, and recalculate the logged output every time you make a change: https://docs.replay.io/reference-guide/print-statements https://docs.replay.io/reference-guide/print-statements Longer-term, we have plans to implement functionality for "persistent object IDs" and tracing individual values over time. No ETA on that, but from what our runtime team has said it's feasible. (We actually have a partial hardcoded implementation of that that we're using to track anything that looks like a React internal "Fiber" data structure, and I used that to build some of our support for the React DevTools: https://blog.replay.io/how-we-rebuilt-react-devtools-with-replay-routines https://blog.replay.io/how-we-rebuilt-react-devtools-with-re... )

jackcviers3 4y ago
Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this. I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.
- acemarke 4y ago
  Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.

jackcviers3 4y ago

Reply to Grandparent and this: Very cool and definitely useful to record and replay the session and modify breakpoint conditions for replay. I wonder if session recording like this could be safely brought to backend systems. You'd almost have to stub every remote call to allow for replayability in isolation of external services, and the potential for data leakage from a downloaded session is also a concern. I'm glad someone else is working on problems and tools like this. I should note I'm not disparaging the use of debuggers in my comments, but lamenting the nature of the process of debugging the types of systems we deploy today, and the largely non-interactive nature tradeoffs we've made for scalability, reliability, availability, and operability. Sometimes I long for the simplicity of a fully self-contained local system, but I know we just don't live in that world anymore, and haven't for a long time now.

acemarke 4y ago
Yeah, data leakage is a concern in the sense that _everything_ about the process gets recorded. (At Replay, all the recordings are encrypted and access-controlled: https://www.replay.io/security-and-privacy https://www.replay.io/security-and-privacy ) The way Replay specifically works is that we fork and modify the Firefox and Chrome browser and Node runtime to add the necessary support for capturing and stubbing all OS-level syscalls, as well as making other changes to ensure near-deterministic playback. So, when the recording gets replayed, the process gets all the same external inputs it did the first time: - https://docs.replay.io/contribute/how-replay-works https://docs.replay.io/contribute/how-replay-works One of our long-term goals is to bring down recording perf overhead enough that we can do "always-on" recording into a buffer, so that the browser or Node just _always_ runs in recording mode, and if something fails the last minute or so of the buffer gets uploaded for analysis.