Repeated GET of /api/v1/notifications Every Few Seconds
Describe the bug
Phanpy repeatedly calls GET /api/v1/notifications?limit=1&since_id=X once every few seconds. After force-reloading Phanpy, the rate dies down, but after a while (unknown how long) it picks up again.
- Which site:
phanpy.ersei.net - Which site version:
2024.07.22.4c0bc62and2024.08.01.818f58b - Which instance:
social.ersei.net
To Reproduce Steps to reproduce the behavior:
- Log into Phanpy
- Normal use of Phanpy (DMs, posting, etc) without closing/reloading the page for a while
- View webserver access logs
Expected behavior
Phanpy uses the streaming APIs and does not call the notification API every second.
Desktop (please complete the following information):
- OS: NixOS
- Browser: Firefox
- Version: 128.0.3
Additional context Add any other context about the problem here.
According to @vyrcossont, this is not a localized issue and she has seen it happen before as well, after Phanpy has been running for a while.
The first spike down coincides with rebooting my computer (and this restarting Phanpy) and the second spike down is from a force-refresh:
Notification rate remains steady while Phanpy is not being actively used but in the background (see plateau when I was asleep/not at computer) but when Phanpy is in use, the notification rate rises sharply.
Custom .env:
PHANPY_CLIENT_NAME=Phanpy
PHANPY_WEBSITE=https://phanpy.ersei.net
PHANPY_LINGVA_INSTANCES=""
PHANPY_DEFAULT_INSTANCE="social.ersei.net"
PHANPY_PRIVACY_POLICY_URL="https://github.com/cheeaun/phanpy/blob/main/PRIVACY.MD"
VITE_APP_ENV=production
Confirming that I've seen the same symptoms starting around this month (using phanpy.social, same Firefox version but on macOS 14) and often enough that I've started closing Phanpy if I'm not going to use it for a while, since it can trip GotoSocial's default per-IP rate limit pretty quickly. I haven't figured out how to reliably reproduce the rapid polling of the notification endpoint.
It's worth noting that both @9p4 and I are using Phanpy with GtS. I don't know if this behavior happens with Mastodon or other Mastodon-API-compatible instances.
May I know what's the call rate?
Currently it should be every 15 seconds if the streaming API fails. Polling stops when page is not visible.
Polling continues if the page is not visible at around 0.177-0.150 requests per second (once every 8 seconds or so).
I'm seeing repeated subscribe/unsubscribes for the notifications in the streaming API
Every time a message is sent in the streaming API, the notification endpoint is called twice. When no message is sent, the notification endpoint is still called occasionally.
Seems to have stabilized after a few days at around 0.5 requests per second.
@9p4 that's still really a lot 😰
As I'm unable to reproduce this on my side, Is it possible for you debug this further on your side? 🙏
I'd love to help debug!
Anything that I can do to help with this?