This failure became normal recently:
=== RUN TestAutoLoopInEnabled
autoloop_testcontext_test.go:318:
Error Trace: /home/runner/work/loop/loop/liquidity/autoloop_testcontext_test.go:318
/home/runner/work/loop/loop/liquidity/autoloop_test.go:804
Error: Not equal:
expected: 80000
actual : 160000
Test: TestAutoLoopInEnabled
autoloop_testcontext_test.go:318:
Error Trace: /home/runner/work/loop/loop/liquidity/autoloop_testcontext_test.go:318
/home/runner/work/loop/loop/liquidity/autoloop_test.go:804
Error: Not equal:
expected: 160000
actual : 80000
Test: TestAutoLoopInEnabled
autoloop_testcontext_test.go:343:
Error Trace: /home/runner/work/loop/loop/liquidity/autoloop_testcontext_test.go:343
/home/runner/work/loop/loop/liquidity/autoloop_test.go:804
Error: Should be true
Test: TestAutoLoopInEnabled
The root cause is them the order of items in c.quoteRequestIn depends on the
order of loopInBuilder.buildSwap calls, which depends on the order of channel
handling in Manager.SuggestSwaps, which depends on the order of map traversal,
which is not determitistic.
Since in the test all the amounts are different, I used amount as a key and
put the expected calls into a map using amount as a key. When I extract an
item from c.quoteRequestIn channel, I find the corresponding item in the map
and remove it. All other logic is preserved.
It used to be set to default (defaultBatchConfTarget = 12) which
could in theory affect fee rate if updateRbfRate() and publish()
were not called before the batch was saved. (Unlikely scenario.)
Method sweepbatcher.Store.FetchBatchSweeps (implementation using real DB) runs
JOIN query to load LoopOut from swaps table. Now the mock does the same.
It is needed to test store and load scenarios in tests.
If the sweep was successfully updated in the batch, no need to
try to add it to all other batches.
Added a test reproducing adding a sweep to both batches without this change.
Previously storing an empty batch would make the batcher fail to start
as spinning up a restored batch assumes that there's a primary sweep
added already. As there's no point in spinning up such batch we can just
skip over it.
Furthermore we'll ensure that we won't try to ever publish an empty
batch to avoid setting the fee rate too early.
This is needed not to break existing client binaries, e.g. `loop listauth`,
Terminal Web, RTL.
The API should be removed in a couple of releases. For now, GetLsatTokens
just prints a warning message about the API being deprecated and that the
client binary should be updated, and calls GetL402Tokens API, as a wrapper.
Type LsatToken used by GetLsatTokens in the past was renamed to L402Token,
but this does not affect binary encoding, so type L402Token can be used
(as part of TokensResponse) without breaking backward compatibility.
Updated release_notes.md.
See https://github.com/lightninglabs/loop/pull/730#discussion_r1579251294
The flags were re-added in hidden mode so that users who specified them
could start the daemon after upgrading. If a flag is used, a deprecation
warning is printed.
Updated release_notes.md.
