forgejo_admin/basketball-api

Fork 1

Bug: Baby Betty has contradictory jersey state across legacy and generic checkout #171

New issue

Closed

opened 2026-03-26 17:06:19 +00:00 by forgejo_admin · 2 comments

forgejo_admin commented

2026-03-26 17:06:19 +00:00

Owner

Type

Bug

Lineage

standalone — discovered during data audit, split from #170

Repo

forgejo_admin/basketball-api

What Broke

Player "Baby Betty" (id=161) has contradictory jersey state:

players table: jersey_option = opt_out, jersey_order_status = pending (set by legacy /jersey/checkout path)
orders table: order #14, status = pending, product_id=1 (Reversible Jersey, $90), custom_data = {"top_size": "L", "shorts_size": "L", "jersey_number": 55}

She started a legacy opt-out (which set pending on player but never completed), then started a new-system reversible order (which created an Order row but never completed payment). Neither path completed. The player record says one thing, the orders table says another.

Repro Steps

SELECT jersey_option, jersey_order_status FROM players WHERE id = 161; → opt_out / pending
SELECT id, product_id, status, custom_data FROM orders WHERE player_id = 161; → order #14, product 1 (Reversible), pending
These contradict — opt_out vs reversible, both pending

Expected Behavior

Player should have a single consistent state reflecting their actual intent. Since neither order completed payment, the cleanest fix is to reset both to none and let the parent re-order.

Environment

Cluster/namespace: prod / basketball-api
Service version/commit: current main
Related alerts: none

Acceptance Criteria

players record for id=161: jersey_option = NULL, jersey_order_status = none
orders record #14: status = canceled
Query sibling players under same parent — include in fix transaction if they also have contradictory state
Verified via SQL query after fix

Constraints

This is a manual data fix, not a code change
Verify Baby Betty is a test account before modifying (check with Lucas if unclear)
Run in a transaction with rollback capability

forgejo_admin/basketball-api#170 — parent bug (webhook sync gap)
project-westside-basketball — project this affects

### Type Bug ### Lineage standalone — discovered during data audit, split from #170 ### Repo `forgejo_admin/basketball-api` ### What Broke Player "Baby Betty" (id=161) has contradictory jersey state: - `players` table: `jersey_option = opt_out`, `jersey_order_status = pending` (set by legacy `/jersey/checkout` path) - `orders` table: order #14, `status = pending`, product_id=1 (Reversible Jersey, $90), `custom_data = {"top_size": "L", "shorts_size": "L", "jersey_number": 55}` She started a legacy opt-out (which set `pending` on player but never completed), then started a new-system reversible order (which created an Order row but never completed payment). Neither path completed. The player record says one thing, the orders table says another. ### Repro Steps 1. `SELECT jersey_option, jersey_order_status FROM players WHERE id = 161;` → `opt_out / pending` 2. `SELECT id, product_id, status, custom_data FROM orders WHERE player_id = 161;` → order #14, product 1 (Reversible), pending 3. These contradict — opt_out vs reversible, both pending ### Expected Behavior Player should have a single consistent state reflecting their actual intent. Since neither order completed payment, the cleanest fix is to reset both to `none` and let the parent re-order. ### Environment - Cluster/namespace: prod / `basketball-api` - Service version/commit: current main - Related alerts: none ### Acceptance Criteria - [ ] `players` record for id=161: `jersey_option = NULL`, `jersey_order_status = none` - [ ] `orders` record #14: `status = canceled` - [ ] Query sibling players under same parent — include in fix transaction if they also have contradictory state - [ ] Verified via SQL query after fix ### Constraints - This is a manual data fix, not a code change - Verify Baby Betty is a test account before modifying (check with Lucas if unclear) - Run in a transaction with rollback capability ### Related - `forgejo_admin/basketball-api#170` — parent bug (webhook sync gap) - `project-westside-basketball` — project this affects

forgejo_admin referenced this issue

2026-03-26 17:07:23 +00:00

Bug: Generic checkout webhook doesn't sync jersey status back to players table #170

forgejo_admin referenced this issue

2026-03-26 22:21:38 +00:00

fix: sync jersey fields to player record from generic checkout webhook #172

forgejo_admin referenced this issue

2026-03-26 22:25:51 +00:00

fix: sync jersey fields to player record from generic checkout webhook #172

forgejo_admin referenced this issue

2026-03-27 03:56:45 +00:00

fix: linearize alembic migration chain to resolve forked 018 revision #181

forgejo_admin referenced this issue

2026-03-27 03:58:47 +00:00

fix: linearize alembic migration chain to resolve forked 018 revision #181

forgejo_admin commented

2026-03-27 21:32:34 +00:00

Author

Owner

Scope Review: NEEDS_REFINEMENT

Review note: review-393-2026-03-27

Template is complete and well-written. Schema claims verified against codebase. Parent bug #170 is resolved (done). No blockers.

One issue found — blast radius on sibling players:

The legacy jersey routes at jersey.py:263-265 and jersey.py:318-319 operate on all players under a parent (for p in parent.players). If Baby Betty (id=161) shares a parent with other players, those siblings may have the same contradictory state.
The ticket only fixes player id=161 and order #14. Sibling players are not checked.

Action needed: Add an acceptance criterion to check for sibling players:

SELECT p2.id, p2.name, p2.jersey_option, p2.jersey_order_status
FROM players p2
WHERE p2.parent_id = (SELECT parent_id FROM players WHERE id = 161);

If siblings have contradictory state, include them in the same fix transaction.

Once the sibling check is added, this ticket is READY.

## Scope Review: NEEDS_REFINEMENT Review note: `review-393-2026-03-27` Template is complete and well-written. Schema claims verified against codebase. Parent bug #170 is resolved (done). No blockers. **One issue found — blast radius on sibling players:** - The legacy jersey routes at `jersey.py:263-265` and `jersey.py:318-319` operate on **all players under a parent** (`for p in parent.players`). If Baby Betty (id=161) shares a parent with other players, those siblings may have the same contradictory state. - The ticket only fixes player id=161 and order #14. Sibling players are not checked. **Action needed:** Add an acceptance criterion to check for sibling players: ```sql SELECT p2.id, p2.name, p2.jersey_option, p2.jersey_order_status FROM players p2 WHERE p2.parent_id = (SELECT parent_id FROM players WHERE id = 161); ``` If siblings have contradictory state, include them in the same fix transaction. Once the sibling check is added, this ticket is READY.

forgejo_admin commented

2026-03-27 22:05:19 +00:00

Author

Owner

Issue body updated per scope review corrections.

forgejo_admin referenced this issue from a commit

2026-03-27 22:13:25 +00:00

fix: add data fix script for contradictory jersey state (#171)

forgejo_admin referenced this issue from a pull request that will close it,

2026-03-27 22:13:58 +00:00

fix: data fix for contradictory jersey state (#171) #197

forgejo_admin referenced this issue