[PAY-3954] Add backend for play count challenge

[faridsalau]

Description

This PR implements a new challenge system that rewards artists when their tracks reach specific play count milestones in 2025. The challenge tracks play counts across all of an artist's tracks and awards $AUDIO tokens when they reach predefined thresholds.

Implementation Details

• Added a new challenge event type track_played that fires when anyone listens to an artist's track
• Created a new challenge manager play_count_milestones_challenge_manager to handle milestone tracking
• Implemented milestone thresholds at 250, 1000, and 10000 plays with rewards of 25, 100, and 1000 $AUDIO respectively
• Added challenge configuration to all environment JSON files (dev, stage, prod)
• Enhanced the play indexing system to dispatch events to both listeners and track owners

Configuration

• Challenge is active in dev and stage environments
• Challenge is configured but inactive in production, pending launch in 2025

Notes

• The challenge is designed to track plays only within the 2025 calendar year
• Artists can earn rewards for each milestone they reach, with a maximum of 3 milestones
• Each milestone is tracked as a separate challenge instance for the user

How Has This Been Tested?

• Configured lower thresholds (1, 2, 3 plays) for dev/stage environments to facilitate testing
• Verified challenge creation, milestone tracking, and reward distribution through manual testing

[changeset-bot]

⚠️ No Changeset found

Latest commit: 75120ce

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

[dharit-tan]

• what happens if when the first time this job is run, the user already has more than 250 plays?
• could you write a test file for this challenge? maybe the case above is a good test case.

[dharit-tan]

nit: is there a way we can move this query into the challenge manager itself instead of here? not sure if possible if user_id is required in the challenge bus dispatch.

[dharit-tan]

OR: can we attach the new challenge to track_listen event instead of adding new track_played event?

[dharit-tan]

just double-checking: the owner_id isn't available from the play event right? just would like to avoid this query if possible. i don't think there's a way around having 2 separate challenge event types tho.

[faridsalau]

yea no owner_id

classPlayInfo(TypedDict):
user_id: int|Noneplay_item_id: intcreated_at: datetimeupdated_at: datetimesource: strcity: strregion: strcountry: strslot: intsignature: str

[alecsavvy]

yeah we don't pass the owner of the track id with the play event, the user_id in there is the user that performed the listen

[dharit-tan]

nit: could move this up to line 140

[dharit-tan]

i think what you have is fine, but i feel like we're doing duplicate work in this fn + update_user_challenges. not sure we need this logic from 187 onwards..

if total_challenges < len(PLAY_MILESTONES) then isn't it safe to create the challenge row but have it marked false? ah but then in generate_specifier we don't actually go grab the next relevant challenge so maybe that won't work.

just thinking out loud, maybe there's a way to avoid the double work, but maybe this is fine. If we get into a scenario where we create a user_challenge row with is_complete = False, would that break things? i think you're successfully avoiding that here though.

[faridsalau]

i think i remember going down a similar path and having records that weren't supposed to exist being created so went down this path for proper challenge creation

[dharit-tan]

approved pending specifier update