Pagination of collections not working properly on Admin UI

[Danil0v3s]

Describe the Bug

Whenever I open a collection I can briefly see the page render everything without pagination and only then the pages get created. We suspect this issue is happening on V2 as well because once in a while we get our API key from S3 rate limited. I could observe the logs are fetching every image I have on s3, we could also see this on another collection taking 8000+ms to load.

 GET /admin/collections/external-transactions 200 in 8340ms
 GET /admin/collections/external-transactions 200 in 7456ms
 GET /admin/collections/external-transactions?limit=10 200 in 728ms
 POST /admin/collections/external-transactions 200 in 232ms
 POST /admin/collections/external-transactions 200 in 211ms
 POST /admin/collections/external-transactions 200 in 205ms
 GET /admin/collections/external-transactions?limit=10 200 in 804ms

By the logs, it seems the first iteration on the page is being requested without the limit?=10 even though I opened via sidebar, triggering a full load.

Link to the code that reproduces this issue

https://github.com/Danil0v3s/payload/tree/pagination-issue

Reproduction Steps

• Run
• Open Posts collection

Observe logs.

Which area(s) are affected? (Select all that apply)

area: ui

Environment Info

Payload: 3.11.0
Node.js: 18.20.3
Next.js: 15.0.3

[Danil0v3s]

I've completed the db migration from v2 to v3, removed all hooks and custom ui fields (just in case) and deployed the v3 on the same droplet my v2 is running and I can see large collections taking a sweet time to load. Both my Droplet and the Postgres instance are on the same region. I can't seem to find anything related to this on the Github issues as well.

Here's two videos, first is v3, second is v2
https://streamable.com/459kez
https://streamable.com/bx6b23

[Danil0v3s]

So @jacobsfletch answered a question on Discord asking me to test 3.12.0 as per #10199 and see if the issue persisted, which indeed persist and told me to come to GitHub open a ticket. Here's more details about my collection:

import type { CollectionConfig } from "payload";

export const ExternalTransactions: CollectionConfig = {
    lockDocuments: false,
    slug: 'external-transactions',
    admin: {
        group: 'Audit',
        pagination: {
            defaultLimit: 5,
            limits: [5, 10, 15],
        },
    },
    fields: [
        {
            name: 'event',
            type: 'text',
            required: true,
        },
        {
            name: 'platform',
            type: 'radio',
            defaultValue: 'patreon',
            required: true,
            options: [
                {
                    label: 'Patreon',
                    value: 'patreon'
                },
                {
                    label: 'MyMiniFactory',
                    value: 'mmf'
                },
            ],
        },
        {
            name: 'transactionData',
            required: true,
            type: 'json',
            admin: {
                disableListColumn: true
            }
        }
    ]
}

Here's the queries it performed when I opened the said collection
orm.txt

One thing that comes to my attention is that there's a query being made to payload_locked_documents with 76431 parameters.. I couldn't execute that query against PG Admin because of the syntax but if I had to guess, I'd start from there regarding the huge time it's taking for the page to load. I could also notice that despite #10199 fixed the pagination, the queries for the collection still goes out with the wrong limit.

I couldn't seem to get the logs dumped to a file so I could compare v2 queries against v3, but the only thing that got my attention was the huge query to locked documents without a count first... Would counting first be faster?

Query: select "id", "event", "platform", "transaction_data", "updated_at", "created_at" from "external_transactions" order by "external_transactions"."created_at" desc limit $1 -- params: [10]

If you guys need a database dumb and/or my collections altogether I can provide

[jmikrut]

Hey @Danil0v3s — I've just pulled down your reproduction and can't replicate the error.

Here's a screencap:

Screen.Recording.2024-12-30.at.10.39.37.AM-compressed.mp4

I'm using Postgres, and I have Drizzle logs turned on where I can see that there are the appropriate amount of payload-locked-documents being queried. I zoomed out the Payload admin UI so you can see that it doesn't initially flash with all documents - it only ever loads ten.

After updating to 3.12.0, you might need to rm -Rf .next in your app to make sure that Next.js isn't caching something from a prior version.

Otherwise, please let me know if you see anything that I've missed. Thank you for your detail - it helps us a lot, and we'll keep this open until we verify that it has been fixed for you!

[Danil0v3s]

Hey @jmikrut, thanks for taking the time to look into it. I've spoken to @jacobsfletch on Discord and he suggested to take a look at the user settings table, and that seems to be the culprit.

I tried erasing the limit from there but wouldn't work so I just cleared the table entirely and it seem to have fixed the issue with the pagination. I didn't have time to check the query to locked documents yet, will come back to this later today.

Jacob mentioned that maybe there could be some mechanism to compare & merge collection vs settings, but that would come later.

Isn't there any way of disabling the locked documents altogether? I tried disabling them per collection but the query was still being done without a count first, as I see for the collection page

[Danil0v3s]

Alright so I had the time to check and this time opening the collection triggers a query to locked documents with the appropriate amount of parameters indeed.

Here's the file just in case:

v3_2.txt

I think we can close this issue. The take-away from this is that after the migration it is good to clean up the preferences table, what you reckon?