This commit introduces a new `IsRunning()` method to the `StateMachine`.
This method allows callers to safely query whether the state machine
is currently active after it has been started and before it has been
stopped.
To ensure thread-safety, the internal `running` status flag is
implemented using `atomic.Bool` (from `sync/atomic`). Without atomic
operations, concurrent accesses to a simple boolean flag from different
goroutines (e.g., one goroutine calling `IsRunning()` while another
executes `Start()` or `Stop()`) could lead to stale reads or data races.
Add a re-usable implementation of the sqldb.TxOptions interface and make
use of this in the various spots (invoices, batch and graph/db) where we
had previously defined individual implementations that were all doing
the same thing.
In this commit, we add the `source_nodes` table. It points to entries in
the `nodes` table. This table will store one entry per protocol version
that we are announcing a node_announcement on.
With this commit, we can run the TestSourceNode unit test against our
SQL backends.
In this commit we add the necessary SQL queries and then implement the
SQLStore's NodeUpdatesInHorizon method. This lets us run the
TestNodeUpdatesInHorizon unit tests against SQL backends.
In this commit, we add the various sqlc queries that we need in order
to implement the following V1Store methods:
- AddLightningNode
- FetchLightningNode
- HasLightningNode
- AddrsForNode
- DeleteLightningNode
- FetchNodeFeatures
These are implemented by SQLStore which then lets us use the SQLStore
backend for the following unit tests:
- TestNodeInsertionAndDeletion
- TestLightningNodePersistence
In this commit, the various SQL schemas required to store graph node
related data is defined. Specifically, the following tables are defined:
- nodes
- node_extra_types
- node_features
- node_addresses
Adds --route_hints flag to sendpayment.
Hints should be JSON encoded (see usage for example).
Adds --route_hints flag to queryroutes.
Errors if blinded paths are set.
In this commit, we start to signal the prod bit for the rbf coop close
feature. We keep our signaling of the staging bit in place to ensure
the protocol continues to work between those nodes in the wild that are
still signaling the bit.
Fixes https://github.com/lightningnetwork/lnd/issues/9852
Here, we use the new options to initialise the reject and channel caches
for the SQLStore (as is done for the KVStore) and also the channel and
node batch schedulers.
Let all the NewTestDB functions return the V1Store interface type
instead of pointers. Then add a manual skip in the TestGraphLoading test
for any non-bbolt backend. We can remove this once all the methods used
by the test have been implemented by the SQLStore. We only need the
manual skip for this one test since it is the only one that doesnt use
MakeGraphTest to init the graph db.
In this commit, we update the batch schedular so that it has the ability
to do read-only calls. It will do a best effort attempt at keeping a
transaction in read-only mode and then if any requests get added to a
batch that require a read-write tx, then the entire batch's tx will be
upgraded to use a read-write tx.
Here we add a new BenchmarkBoltBatching test that helps us benchmark the
performance when writing to a bbolt backend using various different
configurations. We test using N txs for N writes, 1 tx for N writes and
then various configurations when using the TimeScheduler.
In preparation for using the same logic for non-bbolt backends, we adapt
the batch.Schedular to be more generic.
The only user of the scheduler at the moment is the KVStore in the
`graph.db` package. This store instantiates the bbolt implementation of
the scheduler.
In this commit we add more test coverage for the persistence of the
addresses of a LightningNode. This is so that we have unit test coverage
that ensures that all the various address types can be persisted and
that the order of the addresses (within a type) are preserved.
Here we expand TestEdgeInsertionDeletion to assert that the expected
error is returned when AddChannelEdge is called for a channel that has
already been persisted. We also take the opportunity to convert some of
the error checks in the test to use strict error type matching.
Finally, we test that the expected error is returned if
DeleteLightningNode is called for a node that is no longer in the DB.