Replacement for #5988 that is on the main repo so @aryairani has more permissions to fix things, because I can't seem to get transcript output to line up. Do I need some sort of mcp tools on my machine or something?

I usually just run ./scripts/check.sh locally before pushing; that's what I tried to do last night / this morning but stymied by my nix install quirkiness.

Or once it's already on Github, you can use the update transcripts workflow on it. (That's why I had you move the PR.)

... and then manually re-run the CI workflow on it; since Github stops itself from rerunning it automatically after the update-transcripts workflow. It doesn't like starting work on commits that it itself created.

@ceedubs Ok, well it's passing CI now 🙃
But, what's the testing strategy? I don't see it used anywhere, so is that okay? Why or why not?

@aryairani fair question. I manually tested it and thought that I would add a transcript but then realized that I didn't know of a way to test this in a transcript. This is the exception that propagates if you send an interrupt signal to a Unison program (such as ctrl-c during a run). But I don't know of a way to send an interrupt signal to a program from a transcript.

For manual testing I ran the following program and hit ctrl-c after a couple of seconds:

tmp = do
  res = catchAll do
    sleep (seconds +60)
  match res with
    Right () -> ()
    Left err ->
      Debug.trace "I was able to catch" err

This triggered the Left err branch with a Failure whose error type link matches up with the new builtin (#742gldjoim).

Yeah. I guess we can kill a process from Unison, but not fork one...
so it would have to be an integration test or something, that actually ran ucm

I updated the PR instructions to ask for a screenshot of manual testing in the future 🫠

Here is the passing CI run for ca360df
https://github.com/unisonweb/unison/actions/runs/19139747284