Re:Show HN: Retrace – reverse debugging for production CPyth...
by michaelsalim on Tuesday May 12, 2026 @11:04AM
(#48109398)
Congrats to the team for the launch! I helped build a part of this in the past.
The repo is complex but at its core, this is software to record execution without the performance & storage penalty that would usually come with recording all of production.
To do that, they need to make sure that they record anything this is not deterministic, while leaving code that is deterministic to be executed during replay time.
To be honest, I think this is a really hard problem, almost impossible I'd say. There's just so many things that can cause the same execution to cause different results. But last I've seen, the team is slowly squashing each of the edge cases. I think they've now gotten it to be quite stable.
If everything goes well, this is very exciting and I think can revolutionise how we debug production code as an industry. I unfortunately don't run Python code so I can't meaningfully test this. Here's hoping it takes off and one day it'll be ported to the languages I use!
Re:Show HN: Retrace – reverse debugging for production CPyth...
by thedavidprice on Tuesday May 12, 2026 @12:59PM
(#48110983)
I (we) have seen these pieces before: replay, time-travel debugging, tracing, APM, event sourcing, etc. What I haven’t seen is the whole thing work as described in a production setting. I.e. capture enough of a production run that you can replay it locally, get the same inputs/results, and then trace a bad value back to where it came from.
Has anyone seen prior tech that got this whole combination viably working? Or is there true (potential) novelty here in the combination of production replay + value provenance + usable workflow?
Re:Show HN: Retrace – reverse debugging for production CPyth...
by L15p3r on Wednesday May 13, 2026 @09:53AM
(#48121919)
Hi thanks for your interest in Retrace. Currently the way Retrace works means that if you change the code, the replay will likely diverge. This extends to logging statements. The ability to adapt code to allow for what-if reasoning is somethign we're looking at but not currently supported. But I would ask why would you want to? Retrace allows full forward/backwards debugging of execution runs. With this capability what would adding log statements to the replay give you? In terms of performance instrumentation, with no breakpoints the replay will ruin at full speed with no IO wait. You could profile the replay and get a really accurate idea of where the CPU bottlenecks are. Hope this helps answer your questions.
The repo is complex but at its core, this is software to record execution without the performance & storage penalty that would usually come with recording all of production.
To do that, they need to make sure that they record anything this is not deterministic, while leaving code that is deterministic to be executed during replay time.
To be honest, I think this is a really hard problem, almost impossible I'd say. There's just so many things that can cause the same execution to cause different results. But last I've seen, the team is slowly squashing each of the edge cases. I think they've now gotten it to be quite stable.
If everything goes well, this is very exciting and I think can revolutionise how we debug production code as an industry. I unfortunately don't run Python code so I can't meaningfully test this. Here's hoping it takes off and one day it'll be ported to the languages I use!
Has anyone seen prior tech that got this whole combination viably working? Or is there true (potential) novelty here in the combination of production replay + value provenance + usable workflow?