normalized wallet logs

[ekzyis]

Description

We want to normalize the wallet logs. They currently don't link to invoices or withdrawals via foreign keys but store all the data in the JSON context column.

However, afaict, we can't get rid of context entirely since either a) the data we want to show is unrelated to an invoice or b) the invoice was not created yet.

update: Decided to drop the context column anyway to keep it simple. If we really need some information, we can add it back or save it in a relational way.

update: Realized we would lose created invoice for X sats log messages. We log them when we just fetched a user invoice before they get wrapped. Since wrapping can fail, this would mean we would show an error without having shown that we created an invoice.

There are and will most likely be more cases like this so I decided to keep the context column.

So all this PR does is to add the link to the invoice/withdrawal if we already have an invoice/withdrawal id and resolve the context from this link instead of from the JSON column.

TODO:

• resolve context fields required by frontend
• refactor context in frontend? will completely remove client logs in the future and move them to server, too

Regression tests:

• test wallet status derived from logs
• test log messages still show same information in frontend

Additional Context

To not use the JSON column if not necessary, I now also resolve context.status and context.recv (needed for wallet status) from the existing information instead of saving it.

In a future PR, I will replace the logic to derive status with two status column on the Wallet table anyway.

Checklist

Are your changes backwards compatible? Please answer below:

maybe, but I didn't test and we don't care so we just truncate the table

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:

8. Tested successful/failed autowithdrawals, successful/failed p2p zaps (forward error, wrap error) and sending payments (even though sender logs were not changed at all)

For frontend changes: Tested on mobile, light and dark mode? Please answer below:

n/a

Did you introduce any new environment variables? If so, call them out explicitly here:

no

[huumn]

QA for this went fine. As discussed in chat, I'd recommend refactoring this to not require 2N+1 DB dips where N = # log lines.

I'd also recommend thinking about preventing context from (in the future ... perhaps by accident) leaking sender details to receivers and receiver details to senders. Perhaps wallet logs for receiving should never have an invoiceId and for sending should never have a withdrawalId.

[ekzyis]

I'd recommend refactoring this to not require 2N+1 DB dips where N = # log lines.

Done in d204a70

leaking sender details to receivers and receiver details to senders.

I realized I was actually indeed leaking a sender's invoice to the receiver. 👀 Fixed that in 257f48b. I now never return an invoice as the context for a receiver's log.

Perhaps wallet logs for receiving should never have an invoiceId and for sending should never have a withdrawalId.

Mhh, wouldn't we miss out on interesting relationships that way again?

But if we want to do this, we would just need to remove this and this line.

We could also completely drop the invoiceId column and add it back when we actually have sender logs on the server.