Duplicate payments is legacy that we keep alive for accounting purposes.
This commit isolates the deserialization logic for duplicate payments in
its own file, so that regular payment logic and db structure can evolve
without needing to handle/migrate the legacy data.
Previously this was tested as a white box. Database access methods were
duplicated as test code and compared to the return value of the code
under test. This approaches leads to brittle test because it relies
heavily on implementation details. This commit changes this and prepares
for additional test coverage being added in later commits.
To better distinguish payments from HTLCs, we rename the attempt info
struct to HTLCAttemptInfo. We also embed it into the HTLCAttempt struct,
to avoid having to duplicate this information.
The paymentID term is renamed to attemptID.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
Because we now use printRespJSON everywhere where we print RPC
responses as JSON, we can simply instruct the jsonpb marshaler to
use the original snake_case name specified in the proto file for
the JSON field names and not the default camelCase.
This commit adds each channel's short chan id to the `feereport` rpc.
Without this, it can be tedious to lookup more info about a particular
channel since most rpcs only accept short chan ids and not channel
points. For instance, now one can take a channel id from `feereport` and
look it up directly via `getchaninfo` to examine the policy in more
detail.
This fixes a race during channel closing, where the last channel state
update was still not finished when we set the channel close bit in the
database. This lead to a flake during integration tests, where the last
state update would not finish, and the channel wasn't closes
successfully.
We fix it by first unregistering the channel, making sure it is removed
fully from the link before doing the db modification.
This commit renames the `reversed` pagination flag to
`paginate-forwards`, which is off by default. In order to
access older invoices one can set the paginate-forwards flag,
which is more intuitive than setting the reversed flag to false.
Update channel updates and subscription itest to check that close
initiator is appropriately set for cooperative and force closes for the
local and remote party.
Add an initiator enum which allows up to display an unknown value for
channels that are not in the historical chan bucket, rather than having
and ambiguous false value also representing no-value. A both option is
added to cover the case where both parties initiated a close on chain.
Add an optional channel status CloseChannel which will be stored on the
hitsorical channel which is persisted at channel close. This status is
used to set the close initiator for channels that do not complete the
funding flow or we abandon. In follow up commits, this status will be
used to record force and breach closes. The value is written to the
historical channel bucket for diplay over rpc.
This commit adds two new channel statuses which indicate the party that
initatited closing the channel. These statuses are set in conjunction
with the existing commit broadcast status so that we do not need to
migrate existing logic to handle multiple types of closes. This status
is set for locally initiated force closes in this commit because they
follow a similar pattern to cooparative closes, marking the commitment
broadcast then proceeding with tx broadcast. Remote force closes are
added in the following commit, as they are handled differently.
