Load page x keeps incrementing even when nothing can be retrieved about githawk HOT 10 CLOSED

Ya, I've done some digging here and am almost positive its a GH issue. The Link header isn't consistent whatsoever.

from githawk.

Hmm, will investigate. Def shouldn't increase pages when there is nothing, tho sometimes you can keep loading stuff and its all under "Read" (b/c its filtered when you're on Unread).

I might need to tweak the design to make this more obvious. Maybe even an alert after 1-2 pages that's like "New stuff is under Read" or w/e.

Or maybe I put a count under read/unread and you can also see that increment? Dunno.

from githawk.

Just checked this and on both unread and read, the number is just constantly incrementing!

Also on the unread tab, if there are no new notifications then you have to scroll down a tiny bit to see the pagination button.

IMO: The load page button should only show if it's applicable to the content you're viewing - if there isn't 2 pages of unread notifications then don't show it (but then give me the option to when I toggle over to read ones)

from githawk.

Tracked down & fixed

from githawk.

This seems to have resurfaced?

from githawk.

@BasThomas are you sure it's just not loading stuff that is unread?

from githawk.

Nope, and disappeares after 3. Really strange.

from githawk.

Looking in to this it seems like it now only shows the load next (2), then disappears.

poing the link first gives:

"<https://api.github.com/notifications?access_token=xxx&all=true&page=2&participating=false&per_page=100>; rel=\"next\", <https://api.github.com/notifications?access_token=xxx&all=true&page=2&participating=false&per_page=100>; rel=\"last\""

Then after tapping load page 2:

"<https://api.github.com/notifications?access_token=xxx&all=true&page=1&participating=false&per_page=100>; rel=\"first\", <https://api.github.com/notifications?access_token=xxx&all=true&page=1&participating=false&per_page=100>; rel=\"prev\""

I almost think this is a GitHub API issue?

from githawk.

Haven't being seeing this lately, could it be that this has been fixed?

from githawk.

I think by breaking up the requests this no longer happens!

from githawk.