fix: Workout API and production tweaks

[NickSavino]

• updated workout session history endpoint
• added reset_workflow script along with github action
• added ingestion functionality for webhook

[qodo-code-review]

Review Summary by Qodo

Enhance workout API with history aggregation and user deletion webhook support

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Enhanced workout session history endpoint with aggregated set/rep counts
• Added user deletion webhook handler for Clerk integration
• Removed calibration angles from session history query optimization
• Added database reset automation script and GitHub workflow

Diagram

flowchart LR
  A["Clerk Webhook Events"] -->|user.created| B["HandleCreateUserFromClerk"]
  A -->|user.deleted| C["HandleDeleteUserFromClerk"]
  B --> D["Create User in DB"]
  C --> E["Delete User by ClerkID"]
  F["GetUserWorkoutSessionHistory"] -->|Query with JOINs| G["Aggregate Sets/Reps"]
  G --> H["WorkoutSessionHistoryItemDTO"]
  I["Database Reset Script"] -->|AWS SSM| J["Run Migrations"]
  K["GitHub Workflow"] -->|Manual Trigger| I

Loading

File Changes

1. internal/core/service/user.service.go ✨ Enhancement +57/-48

Added user deletion handler for Clerk webhooks

internal/core/service/user.service.go

---

2. internal/core/service/workout/workout_session.service.go ✨ Enhancement +38/-2

Enhanced history endpoint with aggregated metrics

internal/core/service/workout/workout_session.service.go

---

3. internal/db/users.sql.go ✨ Enhancement +9/-0

Added DeleteUserByClerkID database query function

internal/db/users.sql.go

---

View more (6)

4. internal/db/workout_session.sql.go ✨ Enhancement +33/-33

Optimized history query with set/rep aggregation

internal/db/workout_session.sql.go

---

5. internal/http/handlers/auth.handler.go ✨ Enhancement +7/-1

Added user.deleted webhook event handler

internal/http/handlers/auth.handler.go

---

6. scripts/ci/reset_database.sh ⚙️ Configuration changes +28/-0

New database reset automation script

scripts/ci/reset_database.sh

---

7. .github/workflows/reset-database.yml ⚙️ Configuration changes +37/-0

New GitHub workflow for manual database reset

.github/workflows/reset-database.yml

---

8. db/queries/users.sql ✨ Enhancement +3/-0

Added DeleteUserByClerkID SQL query

db/queries/users.sql

---

9. db/queries/workout_session.sql ✨ Enhancement +16/-8

Optimized history query with aggregations

db/queries/workout_session.sql

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 📐 Spec deviations (0)

1. Reset image may be missing 🐞 Bug ⛯ Reliability

Description

reset-database pulls a migrator image tagged with the current github.sha but the workflow never
builds/pushes that tag, so docker pull can fail and the reset becomes non-functional. This is
especially likely when manually dispatching on a commit that wasn’t built/pushed (or after ECR
cleanup).

Code

.github/workflows/reset-database.yml[R30-37]

+      - name: Run database reset
+        env:
+          AWS_REGION: ${{ secrets.AWS_REGION }}
+          ECR_REPO: ${{ secrets.ECR_REPO }}
+          EC2_INSTANCE_ID: ${{ secrets.EC2_INSTANCE_ID }}
+          GITHUB_SHA: ${{ github.sha }}
+        run: |
+          bash ./scripts/ci/reset_database.sh

Evidence

The workflow runs reset_database.sh with GITHUB_SHA from the current workflow run, but does not
include any step to build/push the ${GITHUB_SHA}-migrate image that the script requires. By
contrast, the production deploy workflow explicitly builds & pushes images before migration/deploy.

.github/workflows/reset-database.yml[30-37]
scripts/ci/reset_database.sh[9-23]
.github/workflows/deploy.yml[31-37]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `Reset Database` workflow pulls a migrator image tagged with `${github.sha}-migrate`, but it never builds/pushes that image in the workflow. This can cause `docker pull` to fail and the reset workflow to be unusable.

### Issue Context
`reset_database.sh` constructs `MIGRATOR_IMAGE_URI="...:${GITHUB_SHA}-migrate"` and pulls it on the EC2 host via SSM. The deploy workflow builds/pushes images first; the reset workflow does not.

### Fix Focus Areas
- .github/workflows/reset-database.yml[20-37]
- scripts/ci/reset_database.sh[9-23]

### Suggested fix
Add a build/push step (or a reusable workflow call) before running `reset_database.sh`, or change the workflow to accept an explicit image tag input (e.g., last successful deploy SHA) and use that for `MIGRATOR_IMAGE_URI`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Prod reset weak guard 🐞 Bug ⛨ Security

Description

The new workflow can run goose ... reset against the production DB URL with only a simple
confirm_reset == 'RESET' gate plus a main-branch check, so any actor with workflow_dispatch access
on main can irreversibly wipe prod data. Given the blast radius, this is an unsafe control for
such a destructive operation.

Code

.github/workflows/reset-database.yml[R3-14]

+on:
+  workflow_dispatch:
+    inputs:
+      confirm_reset:
+        description: 'Type RESET to confirm'
+        required: true
+        type: string
+
+jobs:
+  reset-database:
+    if: ${{ inputs.confirm_reset == 'RESET' && github.ref == 'refs/heads/main'}}
+    runs-on: ubuntu-latest

Evidence

The workflow is manually dispatchable and only checks a string input and branch ref, while the
script explicitly fetches a production SSM parameter and runs a database reset command.

.github/workflows/reset-database.yml[3-14]
scripts/ci/reset_database.sh[20-23]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `Reset Database` workflow performs a destructive production database reset with relatively weak guardrails (manual dispatch + simple text confirmation + main-branch check). This leaves room for catastrophic operator error or misuse by anyone who can dispatch workflows on main.

### Issue Context
The script targets `/cgc-2026-prod/api/database_url` and runs `goose ... reset`, which wipes the schema/data.

### Fix Focus Areas
- .github/workflows/reset-database.yml[1-37]

### Suggested fix
Use GitHub Environments for production and require reviewer approval before execution (e.g., `environment: production` with required reviewers), and/or add additional explicit gating (actor allowlist, separate secret token, time-delayed double confirmation) so the reset cannot be run accidentally.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Reset image may be missing 🐞 Bug ⛯ Reliability

reset-database pulls a migrator image tagged with the current github.sha but the workflow never
builds/pushes that tag, so docker pull can fail and the reset becomes non-functional. This is
especially likely when manually dispatching on a commit that wasn’t built/pushed (or after ECR
cleanup).

Agent Prompt

### Issue description
The `Reset Database` workflow pulls a migrator image tagged with `${github.sha}-migrate`, but it never builds/pushes that image in the workflow. This can cause `docker pull` to fail and the reset workflow to be unusable.

### Issue Context
`reset_database.sh` constructs `MIGRATOR_IMAGE_URI="...:${GITHUB_SHA}-migrate"` and pulls it on the EC2 host via SSM. The deploy workflow builds/pushes images first; the reset workflow does not.

### Fix Focus Areas
- .github/workflows/reset-database.yml[20-37]
- scripts/ci/reset_database.sh[9-23]

### Suggested fix
Add a build/push step (or a reusable workflow call) before running `reset_database.sh`, or change the workflow to accept an explicit image tag input (e.g., last successful deploy SHA) and use that for `MIGRATOR_IMAGE_URI`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools