c2fb7d61f7
All checks were successful
build-and-release / build (developers) (push) Successful in 1m41s
build-and-release / build (catering-services) (push) Successful in 1m58s
build-and-release / build (companies) (push) Successful in 2m0s
build-and-release / build (cron) (push) Successful in 2m8s
build-and-release / build (customers) (push) Successful in 2m42s
build-and-release / build (gateway) (push) Successful in 1m2s
build-and-release / build (fitness-trainers) (push) Successful in 1m34s
build-and-release / build (jobs) (push) Successful in 44s
build-and-release / build (employees) (push) Successful in 1m50s
build-and-release / build (graphic-designers) (push) Successful in 2m41s
build-and-release / build (makeup-artists) (push) Successful in 1m49s
build-and-release / build (job-seekers) (push) Successful in 3m2s
build-and-release / build (photographers) (push) Successful in 2m40s
build-and-release / build (payments) (push) Successful in 2m50s
build-and-release / build (social-media-managers) (push) Successful in 2m55s
backend-integration-tests / ai-credits (push) Successful in 52s
build-and-release / build (ugc-content-creators) (push) Successful in 2m37s
build-and-release / build (tutors) (push) Successful in 2m56s
build-and-release / build (video-editors) (push) Successful in 2m41s
build-and-release / build (users) (push) Successful in 4m44s
AI credit purchases (money -> credits via PayU) never generated an invoice, even though the exact same infrastructure already works for TraceCoin purchases in main.rs's generate_purchase_invoice. Spending credits (try_reserve_credits/capture) correctly does NOT get an invoice - only real-money purchases do, matching existing TraceCoin behavior. - invoices.payment_id had a hard FK to payments(id) only, which blocks using it for ai_credit_orders(id) rows. Postgres has no polymorphic FK; dropped the constraint (invoice_type already says which table payment_id points into) via a new migration rather than editing the original invoices migration. - Added generate_ai_credit_invoice in ai_credits.rs, called from verify_order after a successful PayU payment - mirrors main.rs's pattern exactly (same non-blocking failure handling, same seller details via the now pub(crate) seller_details(), invoice_type 'AI_CREDIT_PURCHASE'). - Caught a real bug while writing this: order.amount_inr is the POST-discount final price, but NewInvoice.discount_amount is subtracted again inside compute_totals (subtotal - discount) - using amount_inr directly as unit_price_paise would have double-subtracted the discount. Reconstructed the pre-discount price (amount_inr + discount_applied) for the line item instead. Applied the FK-drop migration to nxtgauge_test and prod; verified the constraint is gone and user_id's FK is untouched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
7 lines
280 B
PL/PgSQL
7 lines
280 B
PL/PgSQL
BEGIN;
|
|
|
|
-- Only safe to restore if every existing row's payment_id is still a valid
|
|
-- payments(id) - true as long as no AI_CREDIT_PURCHASE invoices exist yet.
|
|
ALTER TABLE invoices ADD CONSTRAINT invoices_payment_id_fkey FOREIGN KEY (payment_id) REFERENCES payments(id);
|
|
|
|
COMMIT;
|