Description
After a swap initiates, the contract removes the reservation row (vote_initiate → clear_confirmed_reservation), so get_miner_reserved_until returns 0, which the expiry check in alw swap post-tx (reserved_until <= current_block) reads as expired. It cannot tell an initiated swap from an expired reservation, so it assumes expired: it deletes the local pending-swap record (clear_pending_swap()) and tells the user to start over. alw view reservation hits the same on-chain state but fails soft — it hedges that the reservation may already have advanced into a swap and points at alw view active-swaps — while post-tx asserts expiry outright and directs the user to re-reserve.
Steps to reproduce
- Reserve a miner with
alw swap now, send source funds, and submit them with alw swap post-tx <hash>.
- Wait for the swap to initiate on-chain (the reservation row is removed at that point).
- Run
alw swap post-tx again.
Expected behavior
post-tx recognizes that the reservation became a live swap and points the user at it (swap id + alw view swap <id> --watch) instead of deleting the record and advising a new reservation.
Actual behavior
post-tx prints "Reservation has expired. Run alw swap now to start a new swap." and deletes pending_swap.json, after which alw view reservation reports no reservation.
Impact
A user whose swap actually succeeded is told it expired and loses local tracking of it (the swap itself still completes on-chain). If they follow the on-screen advice and run alw swap now, they reserve a second miner and send source funds again. Re-running post-tx in this window is a directed path, not an accident: post-tx's own retry hint and view reservation's "re-broadcast it with alw swap post-tx <hash>" guidance both send users back to it while validators are confirming. alw swap resume-reservation has the same root cause — it ignores the hydrate_pending_swap False return, then crashes formatting an empty chain id (get_chain('')) — so one fix covers both.
Description
After a swap initiates, the contract removes the reservation row (
vote_initiate→clear_confirmed_reservation), soget_miner_reserved_untilreturns 0, which the expiry check inalw swap post-tx(reserved_until <= current_block) reads as expired. It cannot tell an initiated swap from an expired reservation, so it assumes expired: it deletes the local pending-swap record (clear_pending_swap()) and tells the user to start over.alw view reservationhits the same on-chain state but fails soft — it hedges that the reservation may already have advanced into a swap and points atalw view active-swaps— whilepost-txasserts expiry outright and directs the user to re-reserve.Steps to reproduce
alw swap now, send source funds, and submit them withalw swap post-tx <hash>.alw swap post-txagain.Expected behavior
post-txrecognizes that the reservation became a live swap and points the user at it (swap id +alw view swap <id> --watch) instead of deleting the record and advising a new reservation.Actual behavior
post-txprints "Reservation has expired. Runalw swap nowto start a new swap." and deletespending_swap.json, after whichalw view reservationreports no reservation.Impact
A user whose swap actually succeeded is told it expired and loses local tracking of it (the swap itself still completes on-chain). If they follow the on-screen advice and run
alw swap now, they reserve a second miner and send source funds again. Re-runningpost-txin this window is a directed path, not an accident:post-tx's own retry hint andview reservation's "re-broadcast it withalw swap post-tx <hash>" guidance both send users back to it while validators are confirming.alw swap resume-reservationhas the same root cause — it ignores thehydrate_pending_swapFalse return, then crashes formatting an empty chain id (get_chain('')) — so one fix covers both.