Historical results
A result can be questioned after the run succeeds.
A completed calculation may be challenged weeks later. If its original Python execution was recorded, engineers can investigate the external results and code path behind it.
A calculation that changes on rerun
Suppose a hypothetical Python pricing worker converts an amount using a rate returned by an external service. It completes successfully and stores a price of 8,500 pence for an input of 10,000 pence. Weeks later, a customer expects 9,000 pence. The rate service now returns 0.90; the original run may have received 0.85.
def converted_price(amount_pence, rate_client):
rate = rate_client.current_rate()
return round(amount_pence * rate)
A log containing only the final price cannot tell the team which rate the worker actually used. Rerunning against today’s service response produces a new calculation, not the original one. The example is illustrative; it is not a claim that Retrace has been validated with a specific pricing service or database driver.
Use the recording as evidence
Retrace’s documented architecture records results at supported external boundaries while the Python program runs. During replay, the program runs again against the captured response instead of contacting the live service. If this rate call was covered, an engineer could inspect the rate received by Python, the calculation and the resulting control flow in the debugger.
The original amount_pence also has to be available to the replay, whether retained as an input alongside the recording or obtained through a supported recorded boundary. Retrace does not manufacture missing inputs. The relevant source code, compatible Python environment and recording must be kept for the investigation; a run that was never recorded cannot be reconstructed later.
This can help establish what the recorded application execution did. Whether a real worker’s queue, database, network client or concurrency pattern can be replayed correctly needs a workload-specific test. The compatibility notes describe current coverage and caveats.
Replay is not automatic value provenance
A recording can preserve supported external responses. A replay debugger can expose Python frames, variables and control flow as the code executes again. Those are useful pieces of evidence, but they are not a general, automatic trace of every value’s origin and transformation. Full value-level provenance should be evaluated separately; it is not presented here as a generally available feature.
Read how Python record-replay works and the current pytest quickstart. If your team needs to explain completed calculations, discuss which execution and data boundary to record before the next disputed result arises.