feat(open-payments): add list incoming payments

[raducristianpopa]

Changes proposed in this pull request

• add list incoming payments to OP Client

Context

• fixes (open-payments): list incoming payments #816

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Documentation added
• Make sure that all checks pass

[mkurapov]

This test is setup correctly, but in general makes me confused about the backward pagination parameters.

If we only provide a cursor, like (backwards-pagination allows) then by default we will end up forwards paginating, based on this code in the backend:

rafiki/packages/backend/src/shared/pagination.ts

Lines 9 to 20 in b19919a

	export function parsePaginationQueryParameters({
	first,
	last,
	cursor
	}: PageQueryParams): Pagination {
	return {
	first,
	last,
	before: last ? cursor : undefined,
	after: cursor && !last ? cursor : undefined
	}
	}

would this mean that we should make last required as well in Open Payments API? Only cursor is required:

[wilsonianb]

😬
related:

• Support pagination with after and before both specified open-payments#233
• Update pagination parameters and response open-payments#136

[mkurapov]

I'm in favour of not supporting both parameters (for now) to make the Open Payments pagination type simple & similar to what you describe in comment:

after + count || before + count || count (default forward pagination)

[wilsonianb]

For list responses, we could validate that pagination.hasPreviousPage is false if cursor was not specified (which should be forward pagination from the start).

[mkurapov]

Mostly agree, but I'm not sure it's worth failing the whole request over it, however.

[mkurapov]

@raducristianpopa can we try testing that the list route calls the proper validator, similar to this test? https://github.com/interledger/rafiki/pull/848/files#diff-4f318c2a374cc145f8825fecf95d77b29a728927b5a64ce393897b01becb2b93R37-R38

If it takes too long, I'm going to approve the PR anyway so we can merge it later and working on these route tests at a separate time

[mkurapov]

Mostly agree, but I'm not sure it's worth failing the whole request over it, however.

[mkurapov]

I think we can mock out the get here, so we don't need to .mockResolvedValueOnce(incomingPaymentPaginationResult) on the getSpy below

[mkurapov]

I also think we can remove __esModule: true, because we aren't using a default export

[raducristianpopa]

I think we can mock out the get here, so we don't need to .mockResolvedValueOnce(incomingPaymentPaginationResult) on the getSpy below

If we mock the get, all the tests that are using it will fail:

Test Suites: 1 failed, 1 total
Tests:       8 failed, 26 passed, 34 total

---

I also think we can remove __esModule: true, because we aren't using a default export

When __esModule: true is not specified, we get the following error:

incoming-payment › routes › list › calls get method with correct validator

    Error when making Open Payments GET request: Nock: No match for request {
      "method": "GET",
      "url": "http://localhost:1000/.well-known/pay/incoming-payments",
      "headers": {
        "accept": "application/json, text/plain, */*",
        "content-type": "application/json",
        "authorization": "GNAP accessToken",
        "signature": "sig1=:VYmcFqf6cSzLN10+dG/TnXQI23FxWY/n2/wVbNW4oX+U4rCBHpbT75AaMZOe3qzoUDiQUxZg0fpXjSBxHkNpDw==:",
        "signature-input": "sig1=(\"@method\" \"@target-uri\" \"authorization\");created=1671199508;keyid=\"default-key-id\";alg=\"ed25519\"",
        "user-agent": "axios/1.1.2",
        "accept-encoding": "gzip, deflate, br"
      }
    }

[mkurapov]

Looks good, can merge in once the conflict is resolved