Apparently the %d formatting directive implicitly uses `int` as its data
type, which on i386 systems is int32. So the value math.MaxInt64
overflows that value, which causes the compilation to fail.
We remove the last few calls to UpdateAccount from the
TestAccountService test. Previously, the UpdateAccount call was used in
this test to also _insert_ new accounts and to force the account ID to
be set to specific values. So here we need to instead call the store's
NewAccount method to insert a new account, then we get the AccountID
from the returned value and we need to then use this returned ID (which
is no longer forceable) in the remainder of the tests.
In our mission to replace UpdateAccount, we need
UpdatAccountBalanceAndExpiry to take a negative balance so that we can
use it to replace the behaviour of UpdateAccount as it stands today.
In this commit, we remove one call to the UpdateAccount store method and
replace it with a call to a new UpdateAccountBalanceAndExpiry method
which updates an accounts balance and/or expiry fields and finds the
account via the given ID. This method signature is more appropriate for
a SQL backend than the UpdateAccount method.
In preparation for when we have a SQL DB implementation, we want our
unit tests to run smoothly against all DB backends and have the same
results. To achieve this, we need to turn some errors into global error
variables that can be matched against instead.
In this commit, we do this for the unique constraint violation of the
account label.
In later commits, we will use this `storeAccount` helper quite often.
Instead of needing to remember to update the timestamp outside the call,
it make sense to instead update the timestamp within the function. Yes
this does mean that sometimes we make no overall changes but do update
the timestamp but this is a pretty standard pattern that a "last
updated" timestamp is updated at any point that we re-write a record
(even if it does not have a net change).
This commit adds two new test helpers, NewTestDB and NewTestDBFromPath
in a file that is only built when the test_db_postgres and
test_db_sqlite build flags are not set. When we add sql backends, we
will add helpers with the same names for each new backend. We will then
use the appropriate build flags to run our unit tests against all
backends.
We want to be able to pass different DB implementations to NewService.
In preparation for this, we make it implementation agnostic by letting
it take a `Store` instead of constructing one itself.
This this change, we also let LiT handle the closing of the accounts
Store instead of the accounts service
Update the accounts `Store` and `Service` interfaces take a context.
This is in preparation for when the backend DB of the accounts service
is a SQL store which will have methods that take a context.
We rename the `store.go` file to `store_kvdb.go` to indicate that this
file contains the kvdb implementation of the accounts DB. This is in
preparation for adding a sql-backed implementation later on.
We do this early on in the PR so that any changes that need to be made
during the review process can be easily addressed with fix-up commits
that edit the newly named file.
This is a preparation for bumping the lndclient dependency.
Because each lndclient service mock now needs to implement the
RawClientWithMacAuth method but with a different type, we can't
implement two lndclient service mocks within a single struct, as
that would require us to have two methods with the same name but
different types.
So we split the lnd and rounter mocks into two separate structs.
This commit ensures that a pending payment is associated with the
specific account ID before deducting the in-flight balance from the
available balance.
This commit refactors the in-flight check in the accounts service to
its own function. The in-flight check is also inverted to only check
the states that are not considered as in-flight. This makes the check
forward-compatible with lnd `v0.18.0-beta` which introduces a new
`lnrpc.Payment_INITIATED` state.
This commit adds a prefixed logger that is then used to log trace
information about a payment. This will make it easy to see from the logs
which account ID is making the request, what the request ID is and what
the relavant payment hash is.
In preparation for implementing trace logging that makes it easy to link
state across requests and responses for more informative logs, we add a
new ReqIDToPaymentHashStore interface along with an in-memory
implementation. This can be expanded in future to contain other state
but for now let's just go with the payment hash since that is useful to
have and will provide the user useful information about the payment
corresponding to a log.
In preperation for the trace logging we want to implement in an upcoming
commit (where logs for requests & responsescan be linked via their
request ID), we start adding the request ID to an intercepted account
request/response in this commit.
Add the accounts service to status manager. This will allow us to query
the status of the accounts service and see if it is running or not.
For incoming gRPC requests to the accounts service, we also use the
status manager to check if the accounts service is running or not to
determine if we should let the request through or not.
Ensure that we don't stop the service while we're processing a request.
This is especially important to ensure that we don't stop the service
exactly after a user has made an rpc call to send a payment we can't
know the payment hash for prior to the actual payment being sent
(i.e. Keysend or SendToRoute). This is because if we stop the service
after the send request has been sent to lnd, but before TrackPayment
has been called, we won't be able to track the payment and debit the
account.
It can happen that we see the payment request for a payment coming in,
register it, but then it is failed on the lnd level and basically never
exists in the DB.
In that case we can just stop tracking the payment.
