fix(list_watchers): cap pending-content total at 1000 rows#488
Conversation
batchCountUnanalyzedContent counted every event in the entity tree for every watcher in the list, with no bound. On orgs with even one high-volume watcher (Reddit Digest at 78K+ events) the total_counts CTE took 6-11s, blowing the 10s frontend timeout on /watchers pages. The value drives a list-row badge; the only consumer cares whether the number is "small" or "large", not the exact magnitude. Cap the per-watcher total at 1000 rows. Above the cap the badge reads "1000+" — a notification, not an audit. Below the cap behavior is unchanged.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 70efdb65b3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| SELECT 1 FROM watcher_entities ie | ||
| JOIN current_event_records f ON ${entityLinkMatchSql('ie.entity_id::bigint', 'f')} | ||
| WHERE ie.watcher_id = wid | ||
| LIMIT ${TOTAL_CAP} |
There was a problem hiding this comment.
The new capped subquery counts raw join rows (SELECT 1 ... LIMIT 1000) instead of distinct events, but a watcher can have multiple entity_ids and the same event can match more than one of them. In that case total_count is inflated (and can hit the cap early) while analyzed_count is still deduplicated by event_id, so pending_count becomes overstated for multi-entity watchers. The previous query avoided this with COUNT(DISTINCT f.id).
Useful? React with 👍 / 👎.
github-actions
Bot
added
the
triage:needs-human
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Triage decision: Reasons:
Next: Assigned to @buremba for manual review and resolution of the P1 issue identified in the review comment regarding event deduplication before applying the per-watcher cap. |
2 participants
Summary
`batchCountUnanalyzedContent` joins `current_event_records` for every watcher in the org's list. On orgs with a single high-volume watcher (e.g. Reddit Digest at 78K+ events), `list_watchers` takes 6-11s and `/buremba/watchers/218` blows the 10s frontend timeout.
The count drives a badge consumed only by the list UI; exact value above a threshold doesn't drive any decision. Cap at 1000 — same pattern as GitHub's "99+" notifications.
Test plan