Previously, when handling a sweep we assumed that if a sweep status
was completed, the parent batch was also finished. However, since the
batch confirmation status depends on three on-chain confirmations, it
is possible that a spend notifier was started for a sweep of an active
batch. The notifier would fetch the parent batch from the database, but
because we incorrectly assumed that the parent was confirmed (when it
was not), the DB call would fail with a 'no rows returned' error.
This failure would cause the sweep to fail and the sweep batcher to
stop, resulting in a permanent failure state.
Provide a wrapped store type, exposing ExecTx method with a subset
interface in the callback argument. BaseDB interfaces in instantout,
reservation and sweepbatcher use ExecTx with their subset Querier
instead of whole sqlc.Querier (*sqlc.Queries).
This is needed to make the packages more reusable, so they don't
depend on methods of *sqlc.Queries they don't use.
Previously we may have stored negative costs for some loop out swaps
which this commit attempts to correct by fetching all completed swap,
calculating the correct costs and overriding them in the database.
This data is not used by Batcher since commit
"sweepbatcher: load swap from loopdb, not own store".
Now sweepbatcher.Store depends only on tables sweeps and sweep_batches
and does not depend on swaps, loopout_swaps and htlc_keys, making it
easier to reuse.
This commit changes the time parsing function to use the time.Parse
function instead of the prior manual parsing. Only if the year is
far in the future, we replace it with the current year.
This commit fixes faulty timestamps caused by using unix milliseconds
as unix seconds on startup.
This commit also adds a test for the lightning-terminal issue that first
reported the bug.
This commit adds a postgres store to the loopdb package.
Ths postgres migrator uses a replacer filesystem to replace the
sqlite types to postgres types in the migration.
This commit adds a batch insert to the interface. This greatly reduces
the time the migration will take. It is not implemented for the boltdb, as
we will not be supporting migrating to the boltdb.
