contractcourt: settle invoice when claiming HTLC on-chain #2075
Conversation
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
2 times, most recently
from
2156b9d
to
08746aa
Compare
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
3 times, most recently
from
26e6a97
to
c647d55
Compare
| if !invoicesResp.Invoices[0].Settled { | ||
| t.Fatalf("expected invoice to be settled") | ||
| } | ||
|
|
There was a problem hiding this comment.
You could consider adding test coverage on the unit level. In general, I myself prefer to test things only in an integration test if there is really no other option.
I have an (unmerged) contract resolver test for the outgoingcontestresolver, 33c348b.
But I can also imagine that you consider this too much effort in comparison to the size of the change.
There was a problem hiding this comment.
I opted for the integration test change as we're interested in making sure that the invoice state is reflected correctly within the database. I guess we could have this done at the unit test level though. Let me know if you'd like to proceed with that instead.
There was a problem hiding this comment.
We test lots of database behaviour in unit tests. I'd go for that. Integration tests can be so expensive in maintenance over their full lifetimes. Checking flakes, dirty time.sleeps, etc. Maybe ask a second person for an opinion.
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
from
c647d55
to
0b5a9e9
Compare
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
3 times, most recently
from
a5252ba
to
ef5c3a8
Compare
|
Comments addressed, PTAL @Roasbeef @joostjager |
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
from
ef5c3a8
to
7f672a5
Compare
|
I still think a unit test would've been more appropriate for this PR (see earlier comment above), but if a second reviewer approves, I am good. Other than that, LGTM |
There was a problem hiding this comment.
One style related nit, but other than that, LGTM 🐲
Agree with Joost here that this package could certainly use additional unit tests. I don't think it's worth blocking the merge of this PR as this section is already covered with additional unit tests. Further down the release timeline, if we're in a testing freeze with time to spare, we can circle back and bolster the unit tests in this package. This may be something we want to do in-between 0.6 and the next major release as well, while we gather PRs for the next milestone.
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
from
7f672a5
to
d712219
Compare
Co-authored-by: Joost Jager <joost.jager@gmail.com>
In this commit, we extend the remote/receiver chain claim integration test to assert that the on-disk representation of the invoice on the receiving side (Carol) is marked as settled due to the claiming the HTLC on-chain.
Co-authored-by: Joost Jager <joost.jager@gmail.com>
Previously, contract resolvers that needed to publish a second level tx, did not have access to the original htlc amount. This commit reconstructs this amount from data that is already persisted in arbitrator log. Co-authored-by: Joost Jager <joost.jager@gmail.com>
In this commit, we extend the htlcSuccessResolver to settle the invoice, if any, of the corresponding on-chain HTLC sweep. This ensures that the invoice state is consistent as when claiming the HTLC "off-chain".
wpaulino
force-pushed
the
settle-invoice-on-chain-sweep
branch
from
d712219
to
016add6
Compare
In this PR, we extend the
htlcSuccessResolverto settle the invoice,if any, of the corresponding on-chain HTLC sweep. This ensures that the
invoice state is consistent as when claiming the HTLC "off-chain".
Partly addresses #2032 (the receiver side).