Time-Travel Debugging: Replaying Production Bugs Locally (lackofimagination.org)

Interesting approach. I often get to the same goal by using the replicated state machine pattern. Where all inputs to a system are recorded. Both methods seem to rely on designing your application in a very specific way to be able to replay inputs and deterministically get the same outputs.

What they're describing isn't time travel debugging - https://en.wikipedia.org/wiki/Time_travel_debugging.

I'd call this logging calls to your business logic layer. Then running the logged calls on your business logic layer in a development environment to debug the problem.

Your business logic layer should be separate from your UI/presentation layer.

Makes it easy to test them separately if they're not tightly coupled.

Also if you wanna to reuse your business logic layer in a different UI environment, it's easier to switch to another UI if they're not tightly coupled.

Interesting. I built a sort-of-similar system for executing a series of linked, serially-dependent system commands from the TUI used to manage some of our secure appliances. It made writing and debugging such sequences much easier: each command was represented by a struct containing optional pre, post-success, and post-fail log and status line messages, where status could simply default to log.

It meant that the user received meaningful short updates as things progressed, with detailed information in system logs.

This made it much easier for testers and users to report bugs and for developers to understand what to look for in logs.