Paging through pinned statuses returns incorrect status IDs

[nikclayton]

Steps to reproduce the problem

1. Fetch https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&pinned=true
2. Note response contains 4 statuses, in order, 110589297790798751, 110589300108659684, 110589302317342337, 110589304499321482
3. Response has a link header, <https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&min_id=110589297790798751&pinned=true>; rel="prev"
4. Fetch that link to get the previous page of statuses
5. Response contains 3 statuses, in order, 110589304499321482, 110589302317342337, 110589300108659684
6. Note that those 3 statuses were in the initial page of results, which should never happen

Expected behaviour

Empty page of results, because the link header was set correctly

Actual behaviour

Page of incorrect results duplicating statuses from the previous page of results

Detailed description

I think there's a bug in pagination when returning an account's pinned statuses.

To reproduce, start by fetching https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&pinned=true

There's nothing special about this account as far as I know, I'm experimenting with the suggestions API, and this was one of the accounts that was suggested to me. Then a debug-build assertion in Pachli triggered indicating bad data in the response.

The response from that URL is a page of 4 statuses with these IDs (and created_at), in the following order:

110589297790798751 - 2023-06-22T18:32:47.563Z
110589300108659684 - 2023-06-22T18:33:22.928Z
110589302317342337 - 2023-06-22T18:33:56.636Z
110589304499321482 - 2023-06-22T18:34:29.925Z

First problem: statuses in a timeline are mostly (but not always) reverse-sorted by ID, newest ID first. These appear to be sorted oldest-first (possibly by the time/date they were pinned).

That's not necessarily a bug, but the behaviour is not documented. It may however be the source of the actual bug.

Second problem:

The response to the previous URL included the following link header, with min_id set to the ID of the first status in the previous response (i.e., 110589297790798751).

link: https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&min_id=110589297790798751&pinned=true; rel="prev"

If you follow that URL to get the page of pinned statuses preceding the previous one you get the following three statuses returned, in the following order:

110589304499321482
110589302317342337
110589300108659684

That's correct, in the sense that it is the three statuses that have IDs greater than the min_id parameter. But it's very wrong, in the sense that all three of those statuses were in the previous page of results.

I suspect (but may be wrong) that the handler for pinned statuses should return internal link IDs (e.g., the way the bookmarks API call does) and not status IDs.

Pagination for pinned statuses was added in #25555, so /cc @mjankowski

Mastodon instance

mastodon.social

Mastodon version

v4.3.0-nightly.2024-04-30

Technical details

If this is happening on your own Mastodon server, please fill out those:

• Ruby version: (from ruby --version, eg. v3.1.2)
• Node.js version: (from node --version, eg. v18.16.0)

[FaxriddinMaxmadiyorov]

@nikclayton hi, i want to take this issue

[nikclayton]

I'm just the reporter, probably best if you sync with @andypiper, @ClearlyClaire, or @renchap