v1.6.3
One fix, reported from the field within hours of the 1.6.2 announcement. No breaking changes, no config or schema changes — upgrading is a straight swap of the exe.
Pressing Stop on a recovery step said the step had failed
A restore has already failed. You are on the recovery panel, RESTORE ... WITH RECOVERY is running against a large database, and you press Stop. What came back was:
FAILED at HH:mm:ss: A severe error occurred on the current command.
It had not failed. It had done exactly what you asked — and it said otherwise at the one moment somebody is trying to recover a broken database and needs to know what state it is actually in. That panel exists to tell you the truth about a database when things have already gone wrong, so this was the worst possible place to get a word wrong.
Why it happened. SqlClient reports a command cancelled mid-flight as a SqlException — "A severe error occurred on the current command" — not as the cancellation the panel was watching for. The panel had a correct handler saying "the database is in the same state as before this step", and execution walked straight past it into the general failure handler. The method behind that panel was written after the three call sites that carry the translation, and never got one.
The fix, in two places. The service now translates a cancelled command for every caller. The panel additionally trusts the token directly: whatever the driver throws on the way out, if you pressed Stop then what happened is that you pressed Stop. Both guards read the token and never the message — so a genuine severe error still reports as the failure it is. The same mistake pointing the other way would be worse: it would tell you your database was untouched when a recovery step had just failed against it.
The one other method of the same shape — public, CommandTimeout = 0, takes a cancellation token — has been given the same guard before it can matter, and the remaining execute paths audited.
Full detail in CHANGELOG.md and #427.
Downloads. NineLives.exe is the app, 9lives.exe the CLI; take the -arm64 builds on Windows on ARM. Both are single self-contained executables — no installation. The zips carry both front ends together.
The binaries are unsigned, so SmartScreen will warn on first run (#33); each release carries a build provenance attestation you can verify with gh attestation verify.