What happened
Three sessions whose runner had died days earlier show as Failed (API state dead) in rainier ls. rainier delete <id> --yes on each prints deleted permanently, and rainier ls still lists them as Failed afterwards; info still reports Session: Failed, API state: dead, Delete: yes. Repeating the delete prints the same success line and changes nothing. ls --all shows both a Deleted record and a Failed record for the same name in one case, which suggests the delete path writes a terminal record beside the dead one rather than transitioning it.
Expected
A delete on a session in any state that is not running should either transition the record to deleted (so the default ls drops it) or refuse with a reason. Reporting success while the row is unchanged is the worst of the three: it is not idempotent in effect, only in output.
Likely area
The delete command's handling of the dead/failed terminal states in the control lifecycle (the runner is unreachable, so there is nothing to tear down; the record still needs its state moved), and the hosted regional store's implementation of the same port. The ls default filter hides deleted but not failed, so once the transition is right the listing follows.
Acceptance
A conformance case in controlapp/repotest: a session in dead (and in failed) accepts delete, its state reads deleted afterwards, a second delete is a no-op that still reports success, and the default listing omits it. Both adapters.
What happened
Three sessions whose runner had died days earlier show as
Failed(API statedead) inrainier ls.rainier delete <id> --yeson each printsdeleted permanently, andrainier lsstill lists them asFailedafterwards;infostill reportsSession: Failed,API state: dead,Delete: yes. Repeating the delete prints the same success line and changes nothing.ls --allshows both aDeletedrecord and aFailedrecord for the same name in one case, which suggests the delete path writes a terminal record beside the dead one rather than transitioning it.Expected
A delete on a session in any state that is not
runningshould either transition the record todeleted(so the defaultlsdrops it) or refuse with a reason. Reporting success while the row is unchanged is the worst of the three: it is not idempotent in effect, only in output.Likely area
The delete command's handling of the
dead/failedterminal states in the control lifecycle (the runner is unreachable, so there is nothing to tear down; the record still needs its state moved), and the hosted regional store's implementation of the same port. Thelsdefault filter hidesdeletedbut notfailed, so once the transition is right the listing follows.Acceptance
A conformance case in
controlapp/repotest: a session indead(and infailed) acceptsdelete, its state readsdeletedafterwards, a second delete is a no-op that still reports success, and the default listing omits it. Both adapters.