Summary

The live feed poller (Toolforge continuous job: python -m app.services.poller) calls MediaWikiClient.get_user_contribs / get_article_revisions, which cache results in Redis for 300 seconds.

The poller never bypasses that cache (get_user_contribs has no refresh path). After the first poll fills the cache, new revids can be missed until TTL expiry — WebSocket notifications can lag by up to ~5 minutes plus the poll interval when EventStreams is off (default Toolforge path).

Important detail

Dashboard uses default limit=20 cache keys (contribs:…:20, revisions:…:20). Poller uses limit=10 (…:10). Keys differ — lag is from poller self-caching, not from the dashboard “warming” the poller’s keys.

Code

• backend/app/services/feed_poller.py — poll_once
• backend/app/services/mediawiki.py — CONTRIBS_CACHE_TTL / REVISIONS_CACHE_TTL = 300; get_user_contribs, get_article_revisions

Proposed fix (pick one)

• Always bypass cache for poller-only fetches, or
• Separate poller keys with no write / TTL 0, or
• Add refresh=True to get_user_contribs and pass it from the poller (articles already support refresh)

Interactive dashboard may keep short TTL cache.

Acceptance criteria

• With EventStreams disabled, a new edit becomes notifiable within about one poll interval after MediaWiki shows it
• Dashboard can still use caching for interactive load
• Test (mocked Redis) proves poller does not return a stale revid list when a newer revid exists upstream