Thread:Andrewds1021/@comment-45117243-20201111034700/@comment-9605025-20201111172235

I don't recall where we left this topic on the other thread but I have since contacted staff and they said they were able to reproduce my issues and are looking into it. However, there was no estimated time frame for a fix.

Also since then, the "loading more" actually started working from me with absolutely no changes on my end. At least, none that could reasonably explain it. The first few days it was only a few additional sets of notifications that I could load but now I can load hundreds of notifications.

That said, I still have missing notifications and they are not always older ones. Every few days, I check with the service to get a count of how many read and unread notifications are hidden compared to how many are shown. Since being able to load more, the number of hidden notifications has been around 20. I find that it is always the same notifications. I have never seen a notification re-appear after disappearing. I am also using these checks to see when notifications get removed from the system. Nothing on that end yet.

I do have code that can hide read notifications but it is CSS-only. Also, I have only used it in testing so everything I have said on this issue happened without that code. After seeing how the "load more" works, I am concerned that hiding the notifications may interfere with the loading in some cases. It appears that the loading relies on detecting the scroll position of the list. If one does not have enough unread messages in the initial set, then they won't be able to scroll the list and thus won't be able to load more; even if there are other unread notifications. At least, that is what I think will happen. I haven't actually verified that yet.

Yes, that is the service I am talking about. The default limit is 10 but you can specify a limit up to 50. Going beyond 50 returns an error message. As you may have noticed, when you have more notifications than what has been returned by the service, the returned JSON has more than just the notifications array in it. It also has a "_links" object which in turn should have a "next" string. That string has the query parameters for the next page of results. As you can see, there are 3 parameters, "limit", "page", and "startingTimestamp". "limit" is, by deafault, 10 and is why you get a fixed number of notifications with each request. This is what you can set to 50 to get more at a time. "page" controls the offset of the results. Each "page" contains "limit" results. "startingTimestamp" is an ISO 8601 datetime in the UTC timezone. In other words, it is the format "YYYY-MM-DDThh:mm:ss.sssZ". The returned notifications are limited to events that happened prior to this timestamp. When retrieving additional pages, you should use it to make sure that the list of notifications (and thus the content of each page) does not change between requests. There is one more parameter that is not listed in the link. "contentType" controls the type of events that the request retrieves. If this is not specified, it defaults to just Discussions replies. You provide multiple values by including it multiple times times in the query string. Fandom uses the older multi-value format so the parameter names are identical. I have managed to confirm some of the valid values. So this request would retrieve all notification types and give you 50 results per request. To get the next 50 older notifications, you would use this request (but with "startingTimestamp" added).
 * announcement-target
 * discussion-post
 * discussion-upvote
 * message-wall-post
 * message-wall-thread
 * post-at-mention
 * talk-page-message
 * thread-at-mention