fix: members query in account set

[thevaibhav-dixit]

We were comparing created_at in cala_account_set_member_account_sets and cala_account_set_member_accounts with cursor created form created_at in cala_account_sets and cala_accounts!

[vindard]

Just did some testing with this branch. This is still pretty broken. It's grouping Accounts and then AccountSets in the returned list (sorted by cursor within each group).

For e.g, I'm getting (with time as proxy for cursor ordering):

• Account @ Time 6
• Account @ Time 4
• Account @ Time 2
• AccountSet @ Time 5
• AccountSet @ Time 3
• AccountSet @ Time 1

And if I paginate after Account @ Time 4 I'll get:

• Account @ Time 2
• AccountSet @ Time 3
• AccountSet @ Time 1

We should probably figure out a way to test expected ordering as well

[vindard]

I just added a branch to help with testing pagination. It seeds a list of accounts/accountSets under a chart of accounts account set that we can test pagination through

https://github.com/GaloyMoney/cala/compare/test-pagination

To initialize:

• make reset-deps run-server
• In a separate terminal make run-tf

To test, get the full list with this query, and then in a new tab choose different items to paginate from

{
  accountSet(id: "00000000-0000-0000-0000-100000000000") {
    name
    members(first: 100) {
      edges {
        cursor
        node {
          ... on Account {
            __typename
            id
            name
          }
          ... on AccountSet {
            __typename
            id
            name
          }
        }
      }
    }
  }
}

The bug

After drilling in further with this, the bug I found was that if you try to paginate from an AccountSet specifically (e.g. (AccountSet #7) Withdrawals Control), it will not show its immediate neighbouring AccountSet. It will show all accounts after it, and all AccountSets after it that aren't its immediate neighbour.

[thevaibhav-dixit]

Just did some testing with this branch. This is still pretty broken. It's grouping Accounts and then AccountSets in the returned list (sorted by cursor within each group).

For e.g, I'm getting (with time as proxy for cursor ordering):

• Account @ Time 6
• Account @ Time 4
• Account @ Time 2
• AccountSet @ Time 5
• AccountSet @ Time 3
• AccountSet @ Time 1

And if I paginate after Account @ Time 4 I'll get:

• Account @ Time 2
• AccountSet @ Time 3
• AccountSet @ Time 1

We should probably figure out a way to test expected ordering as well

is this not the expected behaviour ? we are getting all the accounts/ account sets that were created before Time @ 4

[vindard]

is this not the expected behaviour ? we are getting all the accounts/ account sets that were created before Time @ 4

There's no concept of time in the end-user pagination interface I think, we just use that as an implementation detail to do our ordering. If I was looking at the first list and paginating from Time 4 I would expect all items under it in the page, and ordered in the order the page was first presented:

• Account @ Time 2
• AccountSet @ Time 5
• AccountSet @ Time 3
• AccountSet @ Time 1

But to be more correct (like it currently is on main) I would expect the original list to actually be ordered like:

• Account @ Time 6
• AccountSet @ Time 5
• Account @ Time 4
• AccountSet @ Time 3
• Account @ Time 2
• AccountSet @ Time 1

And if I paginated from Time 4 I'd expect the following in the order presented:

• AccountSet @ Time 3
• Account @ Time 2
• AccountSet @ Time 1

[bodymindarts]

why not instantiate the proper type here?

[thevaibhav-dixit]

i was not sure if we could sort the struct... But can try that

[bodymindarts]

doesn't ret have the cursor? Why construct it>?

[thevaibhav-dixit]

yes it does have an end cursor. here i am creating cursor using the first element to better test

[bodymindarts]

This should be from a domain type to another not from a primitive. so From<AccountSetMember>