fix: enforce order of payments

[motorina0]

Summary

The comment (now removed) explains the problem:

    # we have to specify the wallet id here, because postgres and sqlite return
    # internal payments in different order and get_standalone_payment otherwise
    # just fetches the first one, causing unpredictable results

The problem is that by specifying the wallet id the order is not enforced if the same wallet is the sender and the receiver.
An explicit ORDER BY has been added to the SQL statement.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 57.86%. Comparing base (3e341a3) to head (18a3527).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #2313      +/-   ##
==========================================
- Coverage   58.54%   57.86%   -0.68%     
==========================================
  Files          61       61              
  Lines        9185     9184       -1     
==========================================
- Hits         5377     5314      -63     
- Misses       3808     3870      +62     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[prusnak]

I don't understand the logic why sorting by amount is desired and not by some other field (e.g. time comes to my mind).

[dni]

i think its for internal payments, the one sending is negative the one receiving positive

[motorina0]

The original issue was that the extra field was sometimes not correctly fetched for get payment (/api/v1/payments/${paymenHash}). The extra field contains (among others the webhook status).

The extra field is updated like so on core and withdraw extension:

            await update_payment_extra(
                payment_hash=payment_hash,
                extra={
                    "wh_success": r.is_success,
                    "wh_message": r.reason_phrase,
                    "wh_response": r.text,
                },
                outgoing=True,
            )

Having outgoing=True makes the update on the outgoing (negative) payment.

However, now I have just noticed that the call from lnurlp extension does not specify outgoing=True.
This is indeed inconsistent (and fragile).

[motorina0]

However, now I have just noticed that the call from lnurlp extension does not specify outgoing=True.
This is indeed inconsistent (and fragile).

• nvm, lnurlp is not an outgoing payment. Its fine as it is.

[dni]

lgtm