CodeInstances Forks a Run at Any Step, to Run On Live or Try a What-If Answer

CodeInstances v0.6.0 adds fork. Replay runs a program against the whole recording. Fork runs it against the recording up to a step you pick, then lets it carry on from there. You get the past exactly as it happened, and a new future.

Two uses pull this in. The first is picking up where a run went wrong. An agent ran for twenty minutes, called a dozen APIs, and on call nine it got an answer that sent it the wrong way. You don’t want to spend another twenty minutes and another dozen calls getting back to call nine. codeinstances fork -at 9 run.instance answers calls one to eight from the recording in a moment, then sends call nine for real, against today’s servers.

The second is the what-if. Call nine got a 200. What would the program have done with a 503? With -answer 503.json -offline, call nine gets the answer you wrote, and nothing at all goes out: requests the recording has no answer for get a 502 instead of reaching a server. That’s how you test the error path you never managed to trigger, against a real run instead of a mock.

A Fork Is an Instance

The result is a new instance file. It names its parent and the step, and every call in it says where its answer came from: the parent’s call N, given at the fork, sent, or not sent because the fork was offline. So it replays, compares, shrinks and groups like any other run. codeinstances diff run.instance fork.instance shows what the step changed.

The program gets the parent’s clock and random values back in order until they run out, so the part before the step really is the same run. Give another command after -- and you’re forking a changed build against the old run, which is a good way to check a fix against the exact situation that broke.

Where It Can Surprise You

A fork matches requests to the parent’s calls by method, URL and body. If your program changed what it sends before the step, it goes live (or offline) earlier than the step, and fork tells you so. The parent’s secret headers were redacted when it was recorded, so a program that reads a cookie from them gets [redacted]. Record with -keep-secrets if you need to fork through a login. And a fork runs the parent’s command, live unless -offline, so treat a run from someone else the way you’d treat a script from someone else and look at it with show first.

Tested

100 Go tests pass, and the race detector finds nothing. The self-checking demo has 26 checks now. With its servers gone, it forks its first run offline at the order call with a 503 given as the answer, checks the program reports the refused order, and then forks past the last call and checks diff finds the fork the same as its parent. The what-if fork took 25 ms. An independent review found that a kept environment variable such as NO_PROXY could let an “offline” fork reach the network. It also found that a shrunk fork kept a parent it no longer matched, and that the answer file took header values it shouldn’t. All of that is fixed and tested. The result files are in test/results.

Next on the plan is proof: signed instances that show who recorded a run and that nothing changed since. Download v0.6.0, and the reference has every flag.