Files
python-tdd/src
Disco DeDisco 3ad372bc36
All checks were successful
ci/woodpecker/push/pyswiss Pipeline was successful
ci/woodpecker/push/main Pipeline was successful
FT fix CI #342: seed log_tax_debit in test_saved_draw_renders_brief_banner — @taxman ledger sprint left the FT stale
CI pipeline #342 surfaced two errors, both on the same selector failure path:

1. `test_saved_draw_renders_brief_banner_with_next_free_draw_timestamp` (test_game_my_sea.py:1233) — DEFINITELY caused by my @taxman ledger sprint (f44a282). The Brief banner on /gameboard/my-sea/ is now server-driven via the `free_draw_brief_payload` context var, which `my_sea_lock` emits via `log_tax_debit` on the first card of a cycle. This FT bypasses `my_sea_lock` by ORM-creating the MySeaDraw row (`_save_draw_for_user` helper) — no tax-debit emitted, no payload, no banner, selector fails. Fix: explicitly call `log_tax_debit(self.gamer, "free_draw_locked")` after the ORM seed, mirroring what `my_sea_lock` would have done in the real flow. Kept the seed scoped to test 3 only (the only test that asserts the Brief); the other tests using `_save_draw_for_user` (picker phase, saved hand slots, DEL portal, etc.) don't need it.

2. `test_carte_blanche_equip_and_multi_slot_gatekeeper` (test_trinket_carte_blanche.py:82) — selector for `.my-sea-sign-gate-brief` (added in `a133a9c` per polish-9 race fix) fails ONLY in the CI batched run, NOT in isolation (3× local runs pass, including running the full carte test class). The most likely chain: the my_sea FT above fails alphabetically FIRST in the batch, raises NoSuchElement after the 10s wait_for timeout. That can leave the test runner / geckodriver / Firefox in a transient bad state that the next test (carte blanche) inherits. Common signature for this kind of CI-only cascade w. one root cause: fix the upstream test, downstream clears too.

Local sweep: the my_sea fix in isolation passes (12.881s); the full carte class passes (34.456s, 3 tests). Expectation: CI pipeline #343 will clear both errors w. this one-line fix.

If carte still fails on the next CI run after the my_sea fix lands, the next step is to inspect the CI screendump for the carte failure (not synced to local) to see what state the page was actually in.

Code architected by Disco DeDisco <discodedisco@outlook.com>
Git commit message Co-Authored-By:
Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-26 18:19:11 -04:00
..
feat: shop PaymentIntent flow — shop_buy + shop_confirm + stripe_webhook — Chunk 3 of [[project-wallet-shop-expansion]]. Three-endpoint split per the locked Stripe design: webhook is authoritative for fulfillment (resilient to 3DS, browser closes, network drops); sync /shop/confirm is a best-effort UX speedup (fulfills immediately when Stripe.js confirms client-side, no waiting for webhook delivery); both call Purchase.fulfill() which is idempotent — whichever lands first wins, the other becomes a no-op via the status==SUCCEEDED guard. **POST /dashboard/wallet/shop/buy** (form-encoded shop_item_slug): looks up active ShopItem (404 if missing/inactive); enforces max_owned via is_available_for(user) (409 if cap hit, eg already-owned BAND); requires a saved PaymentMethod (402 otherwise — picks most-recent via order_by('-pk').first() per the open-Q note in the scope doc); creates Stripe PaymentIntent (amount=item.price_cents, currency=usd, customer=user.stripe_customer_id, payment_method=pm.stripe_pm_id, automatic_payment_methods={enabled, allow_redirects=never} for in-window 3DS); creates Purchase w. pi.id; backfills pi.metadata.purchase_id via PaymentIntent.modify so the webhook handler can resolve back to the row; returns {client_secret, purchase_id} JSON for Stripe.js confirmCardPayment. **POST /dashboard/wallet/shop/confirm** (form-encoded purchase_id): retrieves PI from Stripe, if status=='succeeded' calls purchase.fulfill(); returns {status} JSON. 404 if the purchase doesn't belong to request.user. Idempotent — re-firing after fulfill is a safe no-op. **POST /stripe/webhook** (csrf_exempt, mounted at root /stripe/webhook so the URL stays stable across app-routing refactors w. Stripe's dashboard config): verifies signature via stripe.Webhook.construct_event against STRIPE_WEBHOOK_SECRET env var (400 on mismatch — Stripe won't retry on 4xx, only 5xx); on payment_intent.succeeded looks up Purchase by metadata.purchase_id w. fall-back to stripe_payment_intent_id (both unique). Unknown event types are no-op 200 (Stripe sends charge.dispute.created etc. + would retry indefinitely on 5xx). New STRIPE_WEBHOOK_SECRET = os.environ.get(...) setting; user swaps it on staging+prod per the live-mode env-var-only decision. TDD — 17 ITs in test_shop_views.py across 3 classes: ShopBuyViewTest (7 cases — login required, success path creates PI + Purchase w. correct shape, PI.create called w. correct args, unknown slug 404, inactive item 404, max_owned 409, no PM 402); ShopConfirmViewTest (5 cases — login required, succeeded PI triggers fulfill, processing PI leaves PENDING, idempotent on already-SUCCEEDED, other user's purchase 404); StripeWebhookViewTest (5 cases — sig mismatch 400, succeeded event triggers fulfill, unknown event type 2xx no-op, duplicate delivery idempotent, unknown purchase_id 2xx no-op). All Stripe API calls mocked via mock.patch('apps.dashboard.views.stripe'). 1208 IT/UT green
2026-05-22 00:42:09 -04:00