lightninglabs
Block on Proof Courier Service Connection Attempt
This PR enhances the reliability of the proof courier service and the robustness of the proof transfer process:
- Blocking Courier Service Connection: Ensures courier service connection attempts are blocking, preventing failures from premature connection usage and simplifying debugging.
-
Proof Transfer Resilience:
- Implements logic to re-attempt proof transfers when backoff attempts are exhausted, avoiding delays until the next service restart.
- Refines logging and error messages to improve debugging.
These updates strengthen the courier service's reliability and make proof transfers more fault-tolerant.
Pull Request Test Coverage Report for Build 14486973988
Details
- 0 of 60 (0.0%) changed or added relevant lines in 5 files are covered.
- 40 unchanged lines in 9 files lost coverage.
- Overall coverage decreased (-0.03%) to 28.341%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % |
|---|---|---|---|
| tapcfg/config.go | 0 | 1 | 0.0% |
| itest/tapd_harness.go | 0 | 2 | 0.0% |
| itest/test_harness.go | 0 | 2 | 0.0% |
| tapfreighter/chain_porter.go | 0 | 24 | 0.0% |
| proof/courier.go | 0 | 31 | 0.0% |
| <!-- | Total: | 0 | 60 |
| Files with Coverage Reduction | New Missed Lines | % |
|---|---|---|
| itest/test_harness.go | 1 | 0.0% |
| proof/courier.go | 1 | 16.55% |
| tapfreighter/chain_porter.go | 1 | 0.0% |
| tapchannel/aux_leaf_signer.go | 2 | 43.08% |
| asset/asset.go | 3 | 48.1% |
| address/address.go | 6 | 67.47% |
| asset/mock.go | 6 | 63.56% |
| commitment/tap.go | 6 | 71.36% |
| address/mock.go | 14 | 88.24% |
| <!-- | Total: | 40 |
| Totals | |
|---|---|
| Change from base Build 14474635473: | -0.03% |
| Covered Lines: | 25912 |
| Relevant Lines: | 91429 |
💛 - Coveralls
IIRC, the issue last time was that an address contained an invalid courier addr, so the proof could never be delivered, meaning the send was never completed.
Does this change resolve that? IIUC now, we'll just block when trying to connect, but after the send has already been confirmed on chain?
IIRC, the issue last time was that an address contained an invalid courier addr, so the proof could never be delivered, meaning the send was never completed.
Does this change resolve that? IIUC now, we'll just block when trying to connect, but after the send has already been confirmed on chain?
@Roasbeef The PR does not address the invalid courier address problem. This PR ensures that we don't try to use a proof courier service connection before it's ready and so potentially avoid an unnecessary backoff and log messages.
@georgetsagk: review reminder @ffranr, remember to re-request review from reviewers when ready
Hmm, not sure what happened in the merge queue... Rebased to re-trigger CI.
