Mitigate API hammering with high notification counts #1997
Description
Hi, you might remember me from such feature suggestions as #1857
Long story short, today we figured out that my use of Gitify has been bringing my team's GHE to its knees 🐼 For a 1-minute period I see Gitify requesting many pages of notifications and then close to 300 each of pulls and reviews. Root cause is I don't clear out old merged PR notifications because I use Gitify which helpfully filters them.
Now I realize this is what it's supposed to do and it's my bad for not cleaning up my notifications. But in my defence:
- The vast majority of those 300 PRs are merged
- Thanks to your gracious addition of merged filtering I never see them in Gitify
- The main reason I use Gitify is to avoid GH notifications because it doesn't do that filtering
I don't think the notifications API provides PR status so avoiding the /pulls is probably impossible. But a couple of other possibilities that come to mind are:
- Option to automatically mark filtered notifications as read
Option to limit considered notifications by number or time- Configurable API call rate limiting
- Even if /pulls is necessary maybe don't grab /reviews for filtered PRs
I guess this is more of a discussion starter than request per se. Thanks for Gitify!
Activity
setchy commentedon May 8, 2025
A great discussion to have - thanks for starting it @grahamj.
To confirm, I assume this option doesn't meet your needs / workflow?
setchy commentedon May 8, 2025
This is a good suggestion, though could be tricky to implement. At the moment the filtering occurs as a post processing step once the raw notifications have been enriched, since some of the filters are actually derived values.
grahamj commentedon May 9, 2025
sigh I did not notice that option, sorry 🤦🏻♂️ That combined with staying on top of my GH notifications should solve the issue for me.
The other ideas might be worth considering anyway though.