discovery: filter shadow-banned hosts from event listings

[dylanjeffers]

Summary

get_events (packages/discovery-provider/src/queries/get_events.py) backs the contests discovery list (and any other event-list consumer). It previously surfaced contests whose host had been shadow-banned, because the existing filter chain only excluded Event.is_deleted == True.

This PR adds a host-shadow-ban filter that combines the two parallel shadow-ban signals the discovery-provider already uses elsewhere — applying both so the filter catches the full shadow-banned population.

The two signals (and why both)

Signal	Source	Catches	Used by today
aggregate_user.score < 0	composite account-quality score from compute_user_score.sql	Audius-impersonators, low-engagement / bot-like accounts, chat-blocked users	handle_save.sql:129, handle_follow.sql:29, handle_repost.sql:94 — feed-action notification suppression
muted_by_karma subquery (sum of muters' follower_count ≥ COMMENT_KARMA_THRESHOLD)	community-driven karma muting via the muted_users table	Users high-follower accounts have specifically reported / muted	get_track_comment_count.py:31-38 — per-user comment hiding

The two catch different (but overlapping) populations. Score-based catches bots and impersonators who may never have been actively reported; karma-mute catches users that influential accounts have explicitly flagged. Applying both means contest discovery hides anyone who falls into either bucket.

Implementation

Inside _get_events, after the existing filter_deleted step:

muted_by_karma = (
    session.query(MutedUser.muted_user_id)
    .join(AggregateUser, MutedUser.user_id == AggregateUser.user_id)
    .filter(MutedUser.is_delete == False)
    .group_by(MutedUser.muted_user_id)
    .having(func.sum(AggregateUser.follower_count) >= COMMENT_KARMA_THRESHOLD)
    .subquery()
)
base_query = base_query.outerjoin(
    AggregateUser, AggregateUser.user_id == Event.user_id
).filter(
    or_(AggregateUser.score >= 0, AggregateUser.score.is_(None)),
    ~Event.user_id.in_(muted_by_karma),
)

• OUTER JOIN on aggregate_user so users without an aggregate row yet (brand-new accounts) aren't accidentally filtered — the or_(... is_(None)) lets them through; only confirmed negative scores are excluded.
• muted_by_karma is lifted from get_track_comment_count.py verbatim (same shape, same COMMENT_KARMA_THRESHOLD constant), so the contest discovery filter applies the exact same per-user check the comment system uses.
• No row duplication: aggregate_user.user_id is a primary key, so the outer join is 1:1 per Event. The IN-subquery doesn't join, so it can't duplicate either.
• add_query_pagination is plain LIMIT/OFFSET with optional include_count; both work correctly with the dual filter.
• get_events_by_ids (the by-ID lookup) is unchanged on purpose. Deep-link lookups for known events shouldn't be silently broken by a discovery-time filter — comment/action surfaces on those pages have their own enforcement paths.

Risk / blast radius

get_events is the single entry point for event-list queries (confirmed via grep — no other callers in src/). Any consumer that wanted to see shadow-banned hosts' events explicitly would need a new flag like include_shadowbanned: bool — I didn't add one because no caller asks for it today; happy to extend if there's a known admin/internal need.

Test plan

• Create two contest events; mark one host's aggregate_user.score = -1. Call get_events(...) → only the non-shadow-banned event is returned.
• Create a contest by a host who has been muted by a set of users whose combined follower counts ≥ COMMENT_KARMA_THRESHOLD (but whose own score >= 0). Confirm that event is also excluded.
• Create a contest by a brand-new user with no aggregate_user row. Confirm their event still appears (the outer join's NULL is allowed through; they're not in muted_by_karma because no one has muted them yet).
• Confirm get_events_by_ids(id=[shadowbanned_event_id]) still returns the event (filter not applied on that path).
• Smoke the contests discovery list in mobile + web after deploy — shadow-banned users' contests should disappear from the grid.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: f42829b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[dylanjeffers]

Closing — wrong repo. The discovery-provider's Flask API was removed in #14236 and get_events.py is now dead code on main (zero callers). The actual /v1/events/remix-contests endpoint lives in the Go API repo. Re-opening the dual shadow-ban filter (score < 0 OR muted_by_karma) over there.