Add filtering options on REST /v1/invoices

[ShahanaFarooqui]

trafficstars

Background

Currently, we do not have any option to filter invoices based on time while sending the GET request. To show time based reports in the UI, we have to fetch the entire list of invoices and filter them locally. It becomes more expensive for nodes with a large number of invoices. The reporting will be faster if we can send the request with from and to parameters to filter the records through API itself.

Your environment

version of lnd: 0.14.1-beta which operating system (uname -a on *Nix): Windows 10 version of btcd, bitcoind, or other backend: 0.21.1

Expected behaviour

Get a filtered list of invoices.

Actual behaviour

Can either fetch the entire list or paginated list.

[tvolk131]

I can give this a shot!

[tvolk131]

@Roasbeef what sort of filtering approach would be better? Two approaches come to mind for me

1. Adhere to Google's AIPs, which specifiy how List methods should handle filtering through a filter string field. This field's behavior is described in detail here. The upside would be an extremely flexible filtering API that allows for AND/OR/NOT operators that can add support for additional fields from the Invoice message without having to update the proto file (since we're only updating the behavior of the already existing filter field). However, this would mean removing the existing pending_only field and instead using filter: "state = OPEN" - or perhaps supporting both during a transitional deprecation period. Maybe a bit of an idealistic approach, but I'd be remiss if I didn't at least mention it.
2. Add min_creation_date and max_creation_date fields. It's a much less flexible option, but simpler to use and builds off of the existing format of ListInvoiceRequest.

[guggero]

Option 1 sounds like adding a whole new "filter language parsing" module to lnd... Though maybe there are libraries out there. Perhaps at some point (after migrating everything to "native" SQL) we can have a GraphQL API that can do all those things in a more generic manner that doesn't require us to implement a lot of business logic in the invoice or payment DB directly.

Until then, I'd rather go with the more simplistic approach of adding a date min/max filter. Because to actually affect the fetch performance, that filtering needs to happen at the DB transaction level.

[tvolk131]

Gotcha, that's sort of what I figured. I'll stick with min_creation_date and max_creation_date. Hoping to have a PR out by tomorrow.

[AbelLykens]

Are you doing (in this issue) what I am requesting in #6796? If so I will close #6796.