- Update assets/client.go to use grpc.NewClient
- Update swap_server_client.go to use grpc.NewClient
- Replace grpc.WithInsecure() with insecure.NewCredentials()
- reset htlcConfirmed when the HTLC conf subscription errors and we re-register
- add regression test ensuring re-registers after a conf error require a fresh
confirmation instead of sweeping on a stale one
In order for the LiT CI jobs to use the `swapserverrpc` protos that
exist on the latest `master` version of the `loop` repo, we need to
update the `lit-setup` action to replace the litd `swapserverrpc`
dependency with the latest version that exists in the `loop` repo.
Fixes a crash window where handleConf updated the batch row to confirmed but
failed before marking sweeps complete, so re-added sweeps spawned a duplicate
batch or kept retrying. Batch confirmation and sweep completion are now
persisted inside a single DB transaction ConfirmBatchWithSweeps, and handleConf
uses the helper to atomically store the batch and the set of confirmed sweeps.
Added TestSweepBatcherConfirmedBatchIncompleteSweeps that runs against the real
loopdb backend, injects a failure mid-transaction, and verifies the database
never ends up with confirmed=true batches paired with completed=false sweeps.
Add a new workflow to run tests for the LiT repository. This includes
setting up dependencies, cloning the repository, and updating the
`go.mod` file to use local Loop modules.
Loop now guards all static-address managers against zero block heights: each
constructor returns an error when invoked with a non-positive current height,
and `loopd` validates the height from `GetInfo` before instantiating them.
Tests and helper code were updated accordingly so we fail fast instead of
registering chain notifications with invalid hints.
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
