4 commits

Author	SHA1	Message	Date
senke	d4fbf2bf84	feat(marketplace): seller transfer state machine matrix — v1.0.7 item B day 1 ... Day-1 foundation for item B (async Stripe Connect reversal worker). No worker code, no runtime enforcement yet — just the authoritative state machine that day 2's code will route through. Before writing the worker we want a single place where the legal transitions are defined and tested, so the worker's behavior can be argued against the matrix rather than implicitly codified across call sites. transfer_transitions.go: * SellerTransferStatus constants (Pending, Completed, Failed, ReversalPending [new], Reversed [new], PermanentlyFailed). * AllowedTransferTransitions map: pending → {completed, failed}; completed → {reversal_pending}; failed → {completed, permanently_failed}; reversal_pending → {reversed, permanently_failed}; reversed and permanently_failed as dead ends. * CanTransitionTransferStatus(from, to) — same-state always OK (idempotent bumps of retry_count / next_retry_at); unknown from fails conservatively (typos in call sites become visible). transfer_transitions_test.go: * TestTransferStateTransitions iterates the full 6×6 matrix (36 pairs) and asserts every pair against the expected outcome. * TestTransferStateTransitions_TerminalStatesHaveNoOutgoing double-locks Reversed + PermanentlyFailed as dead ends at the map level (not just at the caller level). * TestTransferStateTransitions_MatrixKeysAreAccountedFor keeps the canonical status list in sync with the map; a new status added to one but not the other fails the test. * TestCanTransitionTransferStatus_UnknownFromIsConservative documents the "unknown from → always false" policy so a future reader sees the intent. Migration 982 adds a partial composite index on (status, next_retry_at) WHERE status='reversal_pending', sibling to the existing idx_seller_transfers_retry (scoped to failed). Two parallel partial indexes cost less than widening the existing one (which would need a table-level lock) and keep the worker query planner- friendly. Day 2 routes processSellerTransfers, TransferRetryWorker, reverseSellerAccounting, admin_transfer_handler through CanTransitionTransferStatus at every Status mutation, and writes StripeReversalWorker. Day 3 exercises the end-to-end flow (refund → reversal_pending → worker → reversed) in a smoke probe. Checkpoint: ping user at end of day 1 before day 2 per discipline agreed upfront. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-17 14:13:02 +02:00
senke	2583c92d4f	refactor(connect): persist stripe_transfer_id on create + retry — v1.0.7 item A ... TransferService.CreateTransfer signature changes from (...) error to (...) (string, error) — the caller now captures the Stripe transfer identifier and persists it on the SellerTransfer row. Pre-v1.0.7 the stripe_transfer_id column was declared on the model and table but never written to, which blocked the reversal worker (v1.0.7 item B) from identifying which transfer to reverse on refund. Changes: * `TransferService` interface and `StripeConnectService.CreateTransfer` both return the Stripe transfer id alongside the error. * `processSellerTransfers` (marketplace service) persists the id on success before `tx.Create(&st)` so a crash between Stripe ACK and DB commit leaves no inconsistency. * `TransferRetryWorker.retryOne` persists on retry success — a row that failed on first attempt and succeeded via the worker is reversal-ready all the same. * `admin_transfer_handler.RetryTransfer` (manual retry) persists too. * `SellerPayout.ExternalPayoutID` is populated by the Connect payout flow (`payout.go`) — the field existed but was never written. * Four test mocks updated; two tests assert the id is persisted on the happy path, one on the failure path confirms we don't write a fake id when the provider errors. Migration `981_seller_transfers_stripe_reversal_id.sql`: * Adds nullable `stripe_reversal_id` column for item B. * Partial UNIQUE indexes on both stripe_transfer_id and stripe_reversal_id (WHERE IS NOT NULL AND <> ''), mirroring the v1.0.6.1 pattern for refunds.hyperswitch_refund_id. * Logs a count of historical completed transfers that lack an id — these are candidates for the backfill CLI follow-up task. Backfill for historical rows is a separate follow-up (cmd/tools/ backfill_stripe_transfer_ids, calling Stripe's transfers.List with Destination + Metadata[order_id]). Pre-v1.0.7 transfers without a backfilled id cannot be auto-reversed on refund — document in P2.9 admin-recovery when it lands. Acceptable scope per v107-plan. Migration number bumped 980 → 981 because v1.0.6.2 used 980 for the unpaid-subscription cleanup; v107-plan updated with the note. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-17 13:08:39 +02:00
senke	d31f5733d6	chore(release): v1.0.6.2 — subscription payment-gate bypass hotfix ... Closes a bypass surfaced by the 2026-04 audit probe (axis-1 Q2): any authenticated user could POST /api/v1/subscriptions/subscribe on a paid plan and receive 201 active without the payment provider ever being invoked. The resulting row satisfied `checkEligibility()` in the distribution service via `can_sell_on_marketplace=true` on the Creator plan — effectively free access to /api/v1/distribution/submit, which dispatches to external partners. Fix is centralised in `GetUserSubscription` so there is no code path that can grant subscription-gated access without routing through the payment check. Effective-payment = free plan OR unexpired trial OR invoice with non-empty hyperswitch_payment_id. Migration 980 sweeps pre-existing fantôme rows into `expired`, preserving the tuple in a dated audit table for support outreach. Subscribe and subscribeToFreePlan treat the new ErrSubscriptionNoPayment as equivalent to ErrNoActiveSubscription so re-subscription works cleanly post-cleanup. GET /me/subscription surfaces needs_payment=true with a support-contact message rather than a misleading "you're on free" or an opaque 500. TODO(v1.0.7-item-G) annotation marks where the `if s.paymentProvider != nil` short-circuit needs to become a mandatory pending_payment state. Probe script `scripts/probes/subscription-unpaid-activation.sh` kept as a versioned regression test — dry-run by default, --destructive logs in and attempts the exploit against a live backend with automatic cleanup. 8-case unit test matrix covers the full hasEffectivePayment predicate. Smoke validated end-to-end against local v1.0.6.2: POST /subscribe returns 201 (by design — item G closes the creation path), but GET /me/subscription returns subscription=null + needs_payment=true, distribution eligibility returns false. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-17 12:21:53 +02:00
senke	6039a26a99	chore: cleanup old e2e tests, playwright configs, reorganize down migrations ... - Remove old apps/web/e2e/ test suite (replaced by tests/e2e/) - Remove old playwright configs (smoke, storybook, visual, root) - Move down migrations to veza-backend-api/migrations/rollback/ - Remove stale test results and playwright report artifacts Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-18 11:35:26 +01:00