paymod: Activate the new payment flow for good (part 04) #3826
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Removing parameters is hard. Let's just call it legacypay and remove it later. |
rustyrussell
previously requested changes
Jul 8, 2020
There was a problem hiding this comment.
Ack b3b532d
But prefer not to add YA pay flag we'll have to deprecate...
niftynei
reviewed
Jul 9, 2020
cdecker
force-pushed
the
paymod-04
branch
2 times, most recently
from
c83413e
to
a384e69
Compare
|
I removed the |
cdecker
force-pushed
the
paymod-04
branch
2 times, most recently
from
fbb9798
to
6ae5e18
Compare
As suggested during the paymod-03 review it is better to activate the new code right away, and give users an escape hatch to use the legacy code instead. The way I implemented it allows using either `legacypay` or `pay` and then set `legacy` to switch to the other implementation. Changelog-Added: JSON-RPC: The `pay` command now uses the new payment flow, the new `legacypay` command can be used to issue payment with the legacy code if required. Suggested-by: Rusty Russell <@rustyrussell> Suggested-by: ZmnSCPxj <@ZmnSCPxj>
|
Rebased on top of #3792 now in |
This was causing the state flapping test to fail, since we were yielding control of the io_loop, waiting for the blockheight to be reached, and not setting the status beforehand. An interim `paystatus` call would then find a failed leaf and deduce the entire payment failed. Setting it back to the previous state keeps the overall payment pending while we wait.
Tests were timing out, and there is no point in artificially limiting ourselves if we can be quicker.
We were wrongfully identifying all payment failures as blockheight mismatches.
Amount, parent_part_id and own partid can be helpful when debugging.
We were applying the fee exemption to all payments individually, which is ok until we switch to MPP, where amounts change. Also the log entry was referring to the total amount, and not the fee of the payment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the last step in activating the new payment flow.
compatchanges to tests done in the previous parts and now uses the updated RPC everywherelegacyoption topay(andlegacypayin order not to cause param failures) to fall back on the old implementation should there be an issue.We informally decided to activate the new payment flow for everybody and provide an escape hatch, for users that require the legacy payment model.
Open questions
legacypayexposed via JSON-RPC at all, or should we only expose vialegacyflag on thepaycommand?Changelog-None