The fn.WriteFile writes data like os.WriteFile but in sync mode.
Also adds a behaviour flag that enables removal of file on error.
Co-authored-by: Maurice Poirrier Chuden <mauricepoirrier@gmail.com>
Co-authored-by: Greg Weber <1183+gregwebs@users.noreply.github.com>
When notifying the invoice registry for an exit hop htlc we also want to
include its custom records. The channelLink, the other caller of this
method, already populates this field. So we make sure the contest
resolver does so too.
In a rare case when the critical log is triggered when using postgres as
db backend, the `payment` could be nil cause the server is shutting
down, causing the payment fetching to return an error. We now cache its
state before fetching it from the db.
We have two sources which can call `handlePacketSettle`, either through
the link's `<-s.htlcPlex`, or the `<-s.resolutionMsgs`, which means the
`closeCircuit` could be call twice. Previously we already caught this
case inside `closeCircuit`, in that we would return a nil circuit upon
seeing `ErrUnknownCircuit`, indicating the circuit was removed. However,
we still need to account the case when the circuit is the process of
being closed, which is now fixed as we will ignore when seeing
`ErrCircuitClosing`.
In this commit, the ContextGuard struct is re-worked such that the
context that its new main WithCtx method provides is cancelled in sync
with a parent context being cancelled or with it's quit channel being
cancelled. Tests are added to assert the behaviour. In order for the
close of the quit channel to be consistent with the cancelling of the
derived context, the quit channel _must_ be contained internal to the
ContextGuard so that callers are only able to close the channel via the
exposed Quit method which will then take care to first cancel any
derived context that depend on the quit channel before returning.
This is a tradeoff of disk space (and with that cache size) and
compilation speed. Because we're still running into disk full errors
with the full build cache, we remove it for the cross compile step.
Which means we'll do more work each time.
In this commit, we enable a custom payer for the rbf coop close. This
allows us to ensure that the party that started one side of the close
flow pays the fees.
In this commit, we update the core coop close logic with the new custom
payer param. We also expand the existing unit tests to ensure that the
fee is deducted from the proper party.
This preps us for an upcoming change to the rbf coop state machine where
either party can pay for the channel fees. We also add a new test to
make sure the new function adheres to some key properties.
In this commit, we add the state transitions for the new protofsm based
RBF chan closer. The underlying protocol is a new asymmetric co-op close
process, wherein either side can initiate a chan closer, and use their
settled funds to pay for fees within the channel.
In this commit, we add the ability to specify a custom sequence for a
co-op close tx. This'll come in handy later as the new co-op close
process allows a party to set a custom sequence.
In this commit, we add the initial set of states for the new protofsm
based rbf chan closer. A diagram outlining the new states and their
transitions can be found here:
https://gist.github.com/Roasbeef/acc4ff51b9dff127230228a05553cdfe.
Unlike the existing co-op close process, this co-op close can be
restarted at anytime if either side sends a shutdown message. From
there, we'll each obtain a new RBF'd version that can be re-broadcasted.
This commit creates the set of states, along with the environment that
our state machine will use to drive itself forward.
When reporting an error or a success case of a payment to a
blinded paths, the amounts to forward for intermediate hops
are set to 0 so we need to use the receiver amount instead.
Fixes a bug and makes the function more robust. Before
we would always return the encrypted data size of last hop
of the last path. Now we return the greatest last hop payload
not always the one of the last path.
To be able to do MPP payment to multiple blinded routes we need
to add a constant dummy hop as a final hop to every blined path.
This is used when sending or querying a blinded path, to let the
pathfinder be able to send MPP payments over different blinded
routes. For this dummy final hop we use a NUMS key so that we
are sure no other node can use this blinded pubkey either in a
normal or blinded route.
Moreover this helps us handling the mission control data for
blinded paths correctly because we always consider the blinded
pubkey pairs which are registered with mission control when
a payment to a blinded path fails.
