You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Response has a link header, <https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&min_id=110589297790798751&pinned=true>; rel="prev"
Fetch that link to get the previous page of statuses
Response contains 3 statuses, in order, 110589304499321482, 110589302317342337, 110589300108659684
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.
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:
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).
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:
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:
Steps to reproduce the problem
<https://mastodon.social/api/v1/accounts/110589096435209705/statuses?limit=90&min_id=110589297790798751&pinned=true>; rel="prev"
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
, eg. v3.1.2)node --version
, eg. v18.16.0)The text was updated successfully, but these errors were encountered: