Can't scroll back past a limited number of posts

norm commented

2022-08-19 01:11:37 +00:00

Owner

For whatever reason, I can't scroll back more than 10 posts back in my timeline.

norm commented

2022-08-19 02:26:35 +00:00

Author

Owner

Seems like I can scroll back a bit further now but I still can't scroll back past a certain post.

Can't seem to replicate this behaviour on a local test instace for some reason either. No errors in the dev console or in journalctl either.

Seems like I can scroll back a bit further now but I still can't scroll back past a certain post. Can't seem to replicate this behaviour on a local test instace for some reason either. No errors in the dev console or in `journalctl` either.

norm changed title from ~~Can't scroll back past first page~~ to Can't scroll back past a limited number of posts

2022-08-19 06:03:01 +00:00

Johann150 commented

2022-08-19 06:58:53 +00:00

Owner

Others also reported having problems with this, see https://mk.absturztau.be/notes/93wpdkd7tq

I have no idea what the problem could be but since there is no more loading animation I would guess it is a client issue. Can you see in the network tab if it tries to load more notes by any chance?

Others also reported having problems with this, see https://mk.absturztau.be/notes/93wpdkd7tq I have no idea what the problem could be but since there is no more loading animation I would guess it is a client issue. Can you see in the network tab if it tries to load more notes by any chance?

norm commented

2022-08-19 07:07:32 +00:00

Author

Owner

Doesn't look like it tries to load anything else when I hit that point.

Johann150 commented

2022-08-19 08:56:33 +00:00

Owner

The loading animation missing probably means that the client thinks there are no further notes. The way the client checks if there are no notes is by initially requesting one more than the actual limit and then checking the number of notes in the response.

I have a hunch this may be related to the changes made to Notes.packMany for visibility checks: If there is a note that shouldn't be visible to you it will silently be dropped form the list of notes.

In that case the solution would be to either refactor the API pagination to directly include information on whether more content is available or "replenish" the returned list of notes if some are dropped due to visibility checks.

The loading animation missing probably means that the client thinks there are no further notes. The way the client checks if there are no notes is by initially requesting one more than the actual limit and then checking the number of notes in the response. I have a hunch this may be related to the changes made to `Notes.packMany` for visibility checks: If there is a note that shouldn't be visible to you it will silently be dropped form the list of notes. In that case the solution would be to either refactor the API pagination to directly include information on whether more content is available or "replenish" the returned list of notes if some are dropped due to visibility checks.

norm commented

2022-08-20 20:28:02 +00:00

Author

Owner

In that case the solution would be to either refactor the API pagination to directly include information on whether more content is available or "replenish" the returned list of notes if some are dropped due to visibility checks.

The second case might be better compatibility wise for downstream API users though the first one does seem to be a more elegant solution.

> In that case the solution would be to either refactor the API pagination to directly include information on whether more content is available or "replenish" the returned list of notes if some are dropped due to visibility checks. The second case might be better compatibility wise for downstream API users though the first one does seem to be a more elegant solution.

👍 1

Johann150 commented

2022-08-21 07:46:46 +00:00

Owner

Mmh there are quite a few places where this could be a problem...

Ideally we should probably figure out a way to determine note visibility entirely in the database (current reference point generateVisibilityQuery) so we don't have to do these shenanigans. The problem with that is: we would have to determine note visibility recursively to ensure there won't be any notes whose visibility will cause problems when packing them.

Alternatively, we would have to migrate existing note visibilities and modify incoming federated notes to ensure that the visibility level can never make a step "up", like we are now already enforcing for creating local notes since commit 40d9aa6219. Then we could probably determine visibility from looking at one note alone? I guess there would still be some weirdness with specified visibility because that has another level of specifying individual people, so this approach might not even be viable with more consideration.

Mmh there are quite a few places where this could be a problem... Ideally we should probably figure out a way to determine note visibility entirely in the database (current reference point `generateVisibilityQuery`) so we don't have to do these shenanigans. The problem with that is: we would have to determine note visibility *recursively* to ensure there won't be any notes whose visibility will cause problems when packing them. Alternatively, we would have to migrate existing note visibilities and modify incoming federated notes to ensure that the visibility level can never make a step "up", like we are now already enforcing for creating local notes since commit 40d9aa62199dc637039ee7931685195097fe5035. Then we could probably determine visibility from looking at one note alone? I guess there would still be some weirdness with `specified` visibility because that has another level of specifying individual people, so this approach might not even be viable with more consideration.

Schappi commented

2022-08-24 09:09:01 +00:00

I also have this issue. Is there any debug info I can fetch to help?

Johann150 commented

2022-08-24 11:01:12 +00:00

Owner

Thanks, but I'm already pretty sure what the problem is. I'm just not sure what the best solution is and also don't have time to implement it right now.

❤️ 2

puniko commented

2022-08-27 18:18:16 +00:00

Contributor

Thanks, but I'm already pretty sure what the problem is.

can you elaborate, please?

> Thanks, but I'm already pretty sure what the problem is. can you elaborate, please?

Johann150 commented

2022-08-28 15:40:13 +00:00

Owner

I'm pretty sure it is the thing I already explained about Notes.packMany.

I'm pretty sure it is the thing I already explained about `Notes.packMany`.

Johann150 referenced this issue

2022-09-02 15:38:13 +00:00

fix broken timelines #102

Johann150 added the

fix

label 2022-12-23 10:32:08 +00:00

Johann150 commented

2023-02-20 20:13:02 +00:00

Owner

PR #102 has been merged. However according to some reports this does not entirely fix the issue. If you as an admin notice (or are told) that scrolling further does not work on the timeline, please check the log for a message with status ERR and containing violating visibility restrictions.

PR #102 has been merged. However according to some reports this does not entirely fix the issue. If you as an admin notice (or are told) that scrolling further does not work on the timeline, please check the log for a message with status `ERR` and containing `violating visibility restrictions`.

vib commented

2023-02-21 17:55:41 +00:00

Contributor

I have tried it on a local backup of my instance and indeed after scrolling down for a while it stopped and a dropping note due to violating visibility restrictions, note [id] user [my_id] error appeared 2 times in the logs, 2 different notes. When I tried to see the post by its link I also got this error user [my_id] tried to view note [id] violating visibility restrictions.
Is there anything I can do to help troubleshoot?

I have tried it on a local backup of my instance and indeed after scrolling down for a while it stopped and a `dropping note due to violating visibility restrictions, note [id] user [my_id]` error appeared 2 times in the logs, 2 different notes. When I tried to see the post by its link I also got this error `user [my_id] tried to view note [id] violating visibility restrictions`. Is there anything I can do to help troubleshoot?

Johann150 commented

2023-02-21 20:22:10 +00:00

Owner

So the problem @vib helped me figure out is that I was actually not using my own function correctly. Trying to fix it in 32f4bee5e8 makes everything break though, with the error message

Internal error occurred in notes/timeline: Cannot get entity metadata for the given alias "note"

The mentioned alias "note" is presumably referring to this:

.from(() => q, 'note');

So the problem @vib helped me figure out is that I was actually not using my own function correctly. Trying to fix it in 32f4bee5e816ed483f3d42d3aa1ccf15b4d320fc makes everything break though, with the error message ``` Internal error occurred in notes/timeline: Cannot get entity metadata for the given alias "note" ``` The mentioned `alias "note"` is presumably referring to this: https://akkoma.dev/FoundKeyGang/FoundKey/src/commit/57e49712140e62265e21609ad25dc16b618eda63/packages/backend/src/server/api/common/generate-visibility-query.ts#L8

Can't scroll back past a limited number of posts #70