[bug] Timeline jumps to a distant date when scrolling back #399

New issue

Open

opened 2024-06-12 04:26:46 +00:00 by norm · 3 comments

norm commented

2024-06-12 04:26:46 +00:00

Contributor

Version

3e86db24d3

What were you trying to do?

Scrolling down the timeline to read older posts

What did you expect to happen?

Timeline will show older posts regularly (i.e if the oldest post so far was 30 minutes ago, it'll show the newest post as of 30 minutes ago and so on)

What actually happened?

Timeline shows posts from 1-3 months ago and continues from there.

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Version 3e86db24d3 ### What were you trying to do? Scrolling down the timeline to read older posts ### What did you expect to happen? Timeline will show older posts regularly (i.e if the oldest post so far was 30 minutes ago, it'll show the newest post as of 30 minutes ago and so on) ### What actually happened? Timeline shows posts from 1-3 months ago and continues from there. ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

norm referenced this issue from AkkomaGang/akkoma

2024-06-12 04:27:04 +00:00

[bug] Timeline skips to 1 month ago sometimes when scrolling down #799

Oneric commented

2024-06-12 20:27:08 +00:00

Member

Can you provide the API response, including the pagination Link header, from just the page before and after it skipped around? Feel free to replace post content and author fields

Can you provide the API response, including the pagination `Link` header, from just the page before and after it skipped around? Feel free to replace post content and author fields

norm commented

2024-06-13 00:32:38 +00:00

Author

Contributor

sent a message on xmpp since there's too much sensitive stuff to filter out (and I'm not great at using jq)

Oneric commented

2024-06-14 00:06:33 +00:00

Member

Sumarsing current insight and listing related useful jq as examples (though a simple, e.g. Python, script can also achieve the same if that’s easier)

The date skip happens from one TL request to the next, not inside the results from one request.
There’s no boosted or quoted post falling inside the new time range.

# Compact view of related status properties for each status from a query
# (the if is just here for cosmetics)
jq '[
  .[]
  | {
    "id": .id,
    "create": .created_at,
    "edited": .edited_at,
    "quote_id": .quote_id,
    "reblog": (
      if (.reblog) then
        {"id": .reblog.id, "create": .reblog.created_at, "edited": .reblog.edited_at}
      else
        null
      end)
    }
]' < tl_response.json

Looking at all made TL requests and their paginatiok Link header shows
the frontend suddenly stopped following the next link when the skip occurs;
for all other requests the subsequent fetch matches the next link.

jq filter for all API requests and their Link headers if any:

# add the following to filter out failed requests if needed
#     | select(.response.status >= 200 and .response.status < 300)
jq '[
  .log.entries[]
  | select(.request.url|test("/api/v1/"))
  | {
    "time": .startedDateTime,
    "status": .response.status,
    "url": .request.url,
    "link": [.response.headers[] | select(.name=="link").value]
    }
]' < netrequest_log.har

The max_id value the frontend used for the time-skip query instead of the one from the pagination header does not occur in any of the prior or later home TL responses or queries. So far only home TL requests got captured thus we don’t know whether and which other request may have returned it and messed up the frontend’s pagination cursor, or if it was an older locally cached post which for some reason got mixed in. Querying the link from pagination headers yields the expected results.
Analyzing a complete network dump for if/whehre the culprit slipped in (and/or staring really hard at fe’s pagination code) is the next step.

The response body of API requests is in an entry’s .response.content.text and a lon single-line string not directly JSON object. Meaning when searching for a response containing a particular post a "AAApostId" pattern won't work as the actual content will be \"id\":\"AAApostId\"; prob easiest to just grep the the entire HAR for matches of the ID like grep -nEo '.{0,20}AAApostId.{0,20}' and manually check all matches looking like response bodies.

This already confirms it’s definitely a frontend issue though.

Sumarsing current insight and listing related useful `jq` as examples (though a simple, e.g. Python, script can also achieve the same if that’s easier) The date skip happens from one TL request to the next, not inside the results from one request. There’s no boosted or quoted post falling inside the new time range. ```sh # Compact view of related status properties for each status from a query # (the if is just here for cosmetics) jq '[ .[] | { "id": .id, "create": .created_at, "edited": .edited_at, "quote_id": .quote_id, "reblog": ( if (.reblog) then {"id": .reblog.id, "create": .reblog.created_at, "edited": .reblog.edited_at} else null end) } ]' < tl_response.json ``` Looking at all made TL requests and their paginatiok `Link` header shows the frontend suddenly stopped following the `next` link when the skip occurs; for all other requests the subsequent fetch matches the `next` link. `jq` filter for all API requests and their `Link` headers if any: ```sh # add the following to filter out failed requests if needed # | select(.response.status >= 200 and .response.status < 300) jq '[ .log.entries[] | select(.request.url|test("/api/v1/")) | { "time": .startedDateTime, "status": .response.status, "url": .request.url, "link": [.response.headers[] | select(.name=="link").value] } ]' < netrequest_log.har ``` The `max_id` value the frontend used for the time-skip query instead of the one from the pagination header does not occur in _any_ of the prior or later home TL responses or queries. So far only home TL requests got captured thus we don’t know whether and which other request may have returned it and messed up the frontend’s pagination cursor, or if it was an older locally cached post which for some reason got mixed in. Querying the link from pagination headers yields the expected results. Analyzing a complete network dump for if/whehre the culprit slipped in *(and/or staring really hard at fe’s pagination code)* is the next step. The response body of API requests is in an entry’s `.response.content.text` and a lon single-line _string_ not directly JSON object. Meaning when searching for a response containing a particular post a `"AAApostId"` pattern won't work as the actual content will be `\"id\":\"AAApostId\"`; prob easiest to just grep the the entire HAR for matches of the ID like `grep -nEo '.{0,20}AAApostId.{0,20}'` and manually check all matches looking like response bodies. This already confirms it’s definitely a frontend issue though.