Started from CI failure of TestSweepBatcherHandleSweepRace/loopdb [1] that
surfaced ErrBatcherShuttingDown when the AddSweep loop caught a batch right as
it finished. Reproduced via:
go test ./sweepbatcher -run TestSweepBatcherHandleSweepRace/loopdb -cpu=12,4,8 -count=1
Discovered that handleSweeps treated ErrBatchShuttingDown from batch.addSweeps
as fatal, so the batcher exited even though the sweep was already confirmed.
Fixed by treating that error as "batch already done" so we fall through to the
persisted status/monitorSpend path, and added a regression test that
deterministically simulates the shutdown window.
New regression test added:
go test ./sweepbatcher -run TestSweepBatcherHandleBatchShutdown
[1] https://github.com/lightninglabs/loop/actions/runs/19282552307/job/55136597881?pr=1041
Probably the domain has blocked our CI by IP address. This commit go-replaced
the packages with their GitHub versions to fix the CI check "go mod check".
./release.sh v0.31.5-beta fails as of tag v0.31.5-beta:
tag v0.31.5-beta not checked out
This is because it checks the Git tag with `git describe`, but the current
commit has multiple tags and `git describe` returns swapserverrpc/v1.0.18
instead of expected v0.31.5-beta.
In this commit this edge case is addressed.
Previously the daemon crashed with a panic. Now the CLI returns the following
message:
[loop] rpc error: code = Unimplemented desc = Restart loop with --experimental
Also fix --sat_per_vbyte flag.
All these flags were accessed using wrong type (signed vs unsigned int).
Previous version always parsed them as 0 even when set.
Regenerate the manual.
Loop was pinned to commit c44e078c33e0 (tapchannel: support stxo on aux sweeper)
which was merged into "main" branch of taproot-assets as e6ae082c0b4b.
If a SignTx call is slow, the whole presign() function could timeout if all
the calls are done sequentially. In this commit each call is done in a separate
goroutine to reduce total latency.
We forgot to account for change outputs when checking the feerate of
signed transaction. The bug resulted in fee rate overestimation in the
log message.
Presigned sweeps that produce a change output misreported the on-chain fee.
The fee portion was derived from the total swept amount minus only the
first transaction output, so any change output was treated as additional fee.
Update getFeePortionForSweep to subtract the value of every tx output so
the fee portion reflects only the actual miner fee paid. Add regression
coverage that sweeps a presigned input with change and asserts the spend
and confirmation notifications report the corrected fee.
