lightningd: store raw failure message so waitsendpay always has raw_message - #9342
lightningd: store raw failure message so waitsendpay always has raw_message#9342ksedgwic wants to merge 1 commit into
Conversation
57c6313 to
c6502ca
Compare
|
rebased, resolved conflict |
| {NULL, migrate_backfill_bwatch_tables, NULL, NULL}, | ||
| /* Raw BOLT4 failure message, so waitsendpay can report it even | ||
| * after the failure was recorded (issue #9341). */ | ||
| {SQL("ALTER TABLE payments ADD failmsg BLOB;"), NULL, |
There was a problem hiding this comment.
Nice! ALTER TABLE - ADD failmsg BLOB is valid on a STRICT table (BLOB is an allowed strict type), so this won't break test_sqlite_strict_mode!
| ", failindex, failcode" | ||
| ", failnode, failscid" | ||
| ", failupdate, faildetail, faildirection" | ||
| ", failmsg" |
There was a problem hiding this comment.
Should we mention failmsg in the doc comments for wallet_payment_get_failinfo/wallet_payment_set_failinfo in wallet/wallet.h?
There was a problem hiding this comment.
Good point - added a note to wallet_payment_get_failinfo's doc comment: *failmsg is NULL when no raw onion failure message was recorded (local and self-payment failures, and payments that failed before the migration added the column). Kept it as a separate fixup commit for reviewability; will squash before merge.
6494682 to
efcbca5
Compare
|
squashed and rebased |
…essage If a payment's HTLC failure completes before waitsendpay is called, wait_payment() rebuilds the error from the database, which did not persist the raw BOLT4 failure message: a 2019 FIXME in that path set fail->msg = NULL, silently dropping raw_message from the error data. This is the cause of the test_error_returns_blockheight CI flake - the test loses the race occasionally, calls waitsendpay after the failure has landed, and KeyErrors on the missing raw_message. Add a failmsg column to the payments table (with a downgrade drop), persist fail->msg when recording the failure, and read it back in wait_payment. Local and self-payment failures store NULL as before, since no onion failure message exists for them; failed payments recorded before this migration also return NULL, matching the old behavior. The flaky test now also calls waitsendpay a second time, which deterministically takes the database-replay path, so the regression is covered without any timing dependence. Changelog-Fixed: JSON-RPC: `waitsendpay` error data now includes `raw_message` even when the payment already failed before the command was called. Fixes: ElementsProject#9341
efcbca5 to
8297b93
Compare
|
resolved merge conflict and force pushed |
Fixes the
test_error_returns_blockheightCI flake (#9341).waitsendpaybuilds its error from the live failure when it attaches while the payment is still pending, but when the HTLC failure completes first,wait_payment()rebuilds the error from the database - and the raw BOLT4 failure message was never persisted (/* FIXME: We don't store this! */ fail->msg = NULL;, dating to 2019). Sodata.raw_messagesilently disappears exactly whenwaitsendpayloses that race, which is what the test occasionally hits on CI (two master occurrences last week).This PR adds a
failmsgcolumn to the payments table (with a downgrade drop for tools/lightning-downgrade), persistsfail->msgwhen the failure is recorded, and reads it back inwait_payment(). Local and self-payment failures store NULL as before (no onion failure message exists for them), and pre-migration failed payments also return NULL, matching the old behavior.The test now calls
waitsendpaya second time after the failure is recorded, which deterministically exercises the database-replay path - verified that this assertion fails with exactly the CI flake'sKeyError: 'raw_message'when the wait_payment change is reverted, and passes with it.Fixes #9341