Githawk: Inbox unread count limited to 50

[peppy]

Describe the bug
The count on the inbox is limited to 50. Likely API-related.

To Reproduce
Steps to reproduce the behavior:

1. Be inundated with issues you are responsible for.
2. Go to catch up on them in GitHawk
3. Read and reply to some issues
4. Refresh

Expected behavior
The count should drop from the previously displayed number, but instead still shows there are 50 notifications remaining.

Screenshots

Smartphone (please complete the following information):

• Device: iPhoneSE
• OS: iOS 12.1
• Browser -
• Version 1.23.0

[rnystrom]

Can you open TestFlight and paste the inbox API request? When did you start using the app?

FYI the GitHub API doesn't give you historical notifications, just from when you start using the app.

[peppy]

I'm not sure where to find the request in testflight. I've been using the app for months now.

Here's a video of what I'm seeing: https://puu.sh/BVrlP/ab9bd1ca9c.MP4

[dimirc]

I think this is related to pagination with Notification API.

Maybe parsing web version HTML could be a choice if we don’t have the notifications unread count from API?

[BasThomas]

Not so sure if we want to go that far 😅

Would rather approach GitHub to ask for a better API if we'd be seriously considering that 😄

[dimirc]

I was checking the Network History and I see that when loading the notifications, only the first page of 50 records is loaded so this should be why we can only see the badge up until 50, even when in my case I have about 450.

The response Link header has this info:

<https://api.github.com/notifications?
access_token=XXX=false&page=2&participating=false&per_page=50>; rel="next", 

<https://api.github.com/notifications?
access_token=XXX=false&page=8&participating=false&per_page=50>; rel="last"

So we might have 2 choices:

1. Do another request to the “last” page, in my case page 8, and calculate the total notifications based on (pages*pagesize)+lastpagecount
2. Do another request, with per_page=1, so the new response comes with the “last” rel, pointing to a page that will be the total notification count

Maybe number 2 is more direct and reliable, let me know what you think

[ijm8710]

I would def be a fan of this being improved but understand that it’s not a huge value and would def increase api-fetch toll, which you’re probably hesitant to do.

Related, i noticed the badge for “all” only shows unread count. For example I have 44 read notifs/16 unread, the latter badge is what shows for “inbox”; when I switch to “all”, the count shows 12 unread. The 12 is not a true number due to the pagination issue we’ve discussed above. But, would it make sense to have that badge actually reflect true “unread” count of 44?

[BasThomas]

I see what you're getting at, but feel that it would be more confusing than understandable in most cases.

[BasThomas]

Hm, what about "50+" in case we have any next response links?