feat(events): return related.entry_counts on /events/entity#916
Merged
Conversation
The /v1/events/entity endpoint returned only `data`, so every consumer that
resolves a contest through it had to fire a separate
`/tracks/{id}/remixes?only_contest_entries=true&limit=0` just to render the
entry-count badge. This is an N+1 on web Explore's featured contests (one
count request per card) and an extra round-trip on the track-page contest
section and cold/deep-linked contest pages.
Compute per-contest entry counts alongside the events query and return them
under `related.entry_counts`, keyed by the contest's parent track hashid —
mirroring the existing /events/remix-contests discovery endpoint so the client
can prime `useRemixesCount({ isContestEntry: true })` directly. The count uses
the same in-window filter (child track created after contest start, before
end_date, currently listed) and only applies to remix_contest events on track
entities.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The
/v1/events/entityendpoint returned onlydata. Every consumer that resolves a contest through it (useEventIdsByEntityId→getEntityEvents) then had to fire a separate/tracks/{id}/remixes?only_contest_entries=true&limit=0per contest just to render the entry-count badge.This adds
related.entry_countsto the response — keyed by the contest's parent track hashid — mirroring the existing/events/remix-contestsdiscovery endpoint. The client can now primeuseRemixesCount({ isContestEntry: true })directly from the same call.Why
The count-only request is an N+1 on web Explore's featured contests (one per card) and an extra round-trip on the track-page contest section and cold/deep-linked contest pages. The
/events/entitycall already batches all cards into one request, so threading entry counts through it collapses N count requests to zero.useAllRemixContests)useExploreContent→ ContestCard)Details
v1EventsRemixContests: child track created after contest start, beforeend_date, and currently listed (is_current, not deleted, not unlisted).remix_contestevents ontrackentities get a count; each such event is defaulted to0so empty contests prime a definitive "no entries" and still skip the count request.events_responsenow references the existingremix_contests_relatedschema (reused forentry_counts), so SDK regen picks uprelatedongetEntityEvents.Test
TestGetEntityEventsEntryCountsseeds a contest with 2 in-window remixes + 1 pre-window remix and assertsrelated.entry_countscounts only the 2 in-window entries. Fullapipackage suite passes.🤖 Generated with Claude Code