veza/veza-backend-api/tests
senke eedaad9f83 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
..
analytics refactor(backend): unify architecture - migrate analytics handler to core (ADR-001) 2026-02-15 16:18:13 +01:00
contract style(backend): gofmt -w on 85 files (whitespace only) 2026-04-14 12:22:14 +02:00
error_handling [FE-PAGE-015] fe-page: Add Analytics page 2025-12-25 11:25:06 +01:00
filtering_sorting [FE-PAGE-015] fe-page: Add Analytics page 2025-12-25 11:25:06 +01:00
integration refactor(connect): persist stripe_transfer_id on create + retry — v1.0.7 item A 2026-04-17 13:08:39 +02:00
load style(backend): gofmt -w on 85 files (whitespace only) 2026-04-14 12:22:14 +02:00
marketplace style(backend): gofmt -w on 85 files (whitespace only) 2026-04-14 12:22:14 +02:00
pagination [FE-PAGE-015] fe-page: Add Analytics page 2025-12-25 11:25:06 +01:00
performance style(backend): gofmt -w on 85 files (whitespace only) 2026-04-14 12:22:14 +02:00
search [FE-PAGE-015] fe-page: Add Analytics page 2025-12-25 11:25:06 +01:00
security v0.9.1 2026-03-05 19:22:31 +01:00
transactions test(backend): gate testcontainers tests behind VEZA_SKIP_INTEGRATION 2026-04-14 11:45:19 +02:00
two_factor v0.9.1 2026-03-05 19:22:31 +01:00
webhook_delivery [FE-PAGE-015] fe-page: Add Analytics page 2025-12-25 11:25:06 +01:00
api_routes_integration_test.go fix(backend): pass METRICS_BEARER_TOKEN in TestPublicCoreRoutes 2026-04-14 11:44:53 +02:00
verify_auth.sh refonte: backend-api go first; phase 1 2025-12-12 21:34:34 -05:00
verify_p0.sh refonte: backend-api go first; phase 1 2025-12-12 21:34:34 -05:00
verify_timeout.sh refonte: backend-api go first; phase 1 2025-12-12 21:34:34 -05:00