AddSweep now masks cancellation races during its caller-side setup, but
a request can still be accepted by the batcher run loop before the run
context cancellation is selected. If handleSweeps then performs a
context-sensitive store call while shutdown is in progress, a
backend-specific error such as driver.ErrBadConn can still bubble out
through Batcher.Run.
Prefer the run context's terminal error when startup, handleSweeps, or
asynchronous errChan failures happen after the run context has been
canceled. This keeps normal shutdown reporting consistent and avoids
surfacing backend driver errors from the accepted-request and async
error paths.
Log the original run-loop error before returning the context error so
normal shutdown remains debuggable without changing the returned error.
Add regression tests for both covered run-loop races. One lets AddSweep
successfully hand a sweep request to Run, then cancels the run context
from the second GetSweepStatus call while returning driver.ErrBadConn.
The other queues an errChan error from the event loop while canceling
the run context. Both tests assert that Run returns context.Canceled and
does not wrap the driver error.
The Parameters struct describes the keys, expiry and pkScript that
define the static address script, so its natural home is the script
package. Moving it there lets staticutil drop its dependency on the
address package and lets callers reuse a single type alongside
script.StaticAddress and script.NewStaticAddress.
No behavior change.
Closes#1056
The sqlite and postgres race jobs were both hanging in
deposit.TestManager. The test was observing the manager through
implementation details that were not safe to share with the manager
itself:
- it replaced the manager's internal finalizedDepositChan and then
waited on the same channel the manager consumes
- it reused package-level block and confirmation channels across runs
- it treated confirmationHeight+expiry as the last pre-expiry block
even though the production IsExpired check uses >=
- it relied on scheduler timing when asserting that no sign request
had happened yet
Make the test assert on stable effects instead of internal channel
ownership:
- create per-test notifier channels in the test context
- run the manager from a cancellable t.Context-derived context and
assert clean shutdown
- send the actual last pre-expiry height, then the expiry height
- wait for the expiry sign and publish steps with bounded timeouts
- verify finalization by waiting for the manager to remove the
deposit from activeDeposits instead of racing its private
finalization channel
This keeps the test aligned with the production expiry semantics
and removes the race that only showed up reliably under -race.
Add --max_swap_fee_sat and --max_swap_fee_ppm flags to `loop static in`.
When set, the resolved cap is checked against the current quote before
confirmation and sent in MaxSwapFeeSatoshis instead of the quoted fee,
giving scripts a budget ceiling without the quote-then-retry workaround.
Add resolveMaxSwapFee helper that computes an effective maximum swap fee
from --max_swap_fee_sat and --max_swap_fee_ppm CLI flags. When both are
set the tighter (lower) cap wins. The helper also rejects early if the
server-quoted fee already exceeds the resolved cap.
