Refactor Workout Logging and Streak Tracking

[cejiogu]

Overview

In this PR, I implement a comprehensive refactor of workout tracking and streak logic, including:

• Transitioning backend time handling to UTC
• Implementing historical workout goal tracking
• Refactoring active/max streak computation to respect goal changes over time
• Adding totalGymDays and streakStart fields to the GraphQL User type
• Implementing bug fixes to the logWorkout mutation to consider specific workout facilities

Changes Made

Change 1: Workout Logging Modification

• Fixed edge cases where duplicate workouts could be logged for the same user/day
• Corrected streak calculation logic when logging workouts retroactively

Change 2: GraphQL User Type Modification

• Added a totalGymDays field, which represents the total number of distinct days that a user has logged a workout
• Modified the goalHistory field to be defined as a list of GraphQL Workout objects instead of days of the week
• Changed the workoutGoal field to be defined as integers
• Added a streakStart field, which represents the day that the most recent streak has began, if the user is currently in a streak

Change 3: Streak Logic Refactor

• Transition streaks to rolling 7-day windows, counting distinct workout days per window
• Refactored logic to:
  • Correctly compute the activeStreak and maxStreak fields on the User type while respecting shifts in workout goals
  • Maintain streaks, given the user logs at least one workout in a given week
  • Update the streaks (active/max) of a user whenever a user reaches their workout goal for the given week

Change 4: Refactor Workout Goal History Tracking

• Backend now keeps track of historical goal changes and when each change goes into effect
• Transitioned implementation from Strings to list of Workouts
• Implemented 30-day cooldown on weekly workout goal updates
• Convert workout goals from specific days of the week to a number of days in a 7-day period

Test Coverage

What I Tested

Streak and Workout Goals

• Streak continuity when under goal: Verified that logging ≥1 workout day in a 7-day window preserves the active streak (does not reset), while only incrementing when the goal is met
• Streak increments when goal met: Verified active streak increases when the current window’s distinct workout days meet/exceed goal
• Goal shifts respected historically: Verified active/max streak calculations respect goal effective dates across multiple goal updates (no retroactive re-scoring)
• Goal changes between workouts: Verified increasing/decreasing the goal mid-cycle does not incorrectly change the current window’s scoring
• lastStreakStart correctness: Verified returned value corresponds to the first workout day in the earliest goal-met window of the active streak
  • returned as GraphQL Date scalar in order to avoid timezone drift, which would result in discrepancies between the actual logged date and the returned date

Goal Update Constraints

• 30-day cooldown enforced: Verified setWorkoutGoals rejects updates within 30 days of the last goal change and succeeds when outside the window.

Workout Logging Correctness

• Duplicate prevention: Verified logWorkout does not consider multiple workouts logged during the same day as distinct contributions to the user's workout goal
• Retroactive logging: Verified retroactive workouts update streak metrics deterministically

Timezone/UTC Consistency

• Timezone-agnostic: Verified that, despite normalizing all timestamps to UTC for storage and streak computations, a user's active and max streaks behave consistently (no off-by-one day issues in returned streak fields)

How I Tested

• Used GraphQL (mutations + queries) and mock data to ensure actual outputs matched expected outputs

[JoshD94]

LGTM. one worry i have though is calculating the streaks look like they take a while, so if we have a feature like leaderboards for example that would need multiple user's streaks calculated, it may not be instant? Thoughts on this @cejiogu ?