Preserve bounty payout metadata when creating payment

[BogdanMaryniuk]

Summary

• preserve existing bounty submission metadata when creating a CoinPay bounty payout
• keep previous audit/sync fields (for example expired payment metadata) while new payment details take precedence
• add a regression assertion covering metadata preservation

Tests

• pnpm vitest run src/app/api/bounties/[id]/submissions/[sid]/pay/route.test.ts
• pnpm type-check
• pnpm eslint src/app/api/bounties/[id]/submissions/[sid]/pay/route.ts src/app/api/bounties/[id]/submissions/[sid]/pay/route.test.ts

[greptile-apps]

Greptile Summary

This PR merges pre-existing bounty_submissions.metadata into the new payment metadata object before persisting, so audit/sync fields (e.g., expired invoice IDs, reviewer notes) survive across re-invoicing cycles. A targeted regression test confirms both old and new metadata keys land in the final UPDATE payload.

• route.ts: Extracts existingMetadata from submission.metadata with a proper null/array guard, then spreads it first in the metadata object so new payment fields (payment_address, expires_at, etc.) always override any same-named legacy keys.
• route.test.ts: Adds pre-existing metadata to the fixture and extends the existing assertion to verify the merged result.

Confidence Score: 5/5

Safe to merge — the production code change is a three-line, well-guarded spread that correctly preserves audit metadata while letting fresh payment fields win on collision.

The implementation correctly guards against null, array, and primitive values before spreading, and the spread order guarantees new payment fields always override stale ones. The test adds useful regression coverage for the preservation case, though it stops short of asserting the override behavior for conflicting keys.

route.test.ts — the fixture could include a conflicting key to pin the override guarantee.

Important Files Changed

Filename	Overview
src/app/api/bounties/[id]/submissions/[sid]/pay/route.ts	Adds existingMetadata extraction with null/array guard and spreads it before new payment fields in the DB update — correct and minimal change.
src/app/api/bounties/[id]/submissions/[sid]/pay/route.test.ts	Adds pre-existing metadata to the fixture and asserts preservation; does not cover the key-override scenario (old payment_address overridden by new one), leaving that edge unchecked.

Sequence Diagram

sequenceDiagram
    participant Client
    participant Route as POST /pay route
    participant DB as Supabase (bounty_submissions)
    participant CP as CoinPayPortal

    Client->>Route: POST request
    Route->>DB: SELECT submission (includes metadata)
    DB-->>Route: "submission { metadata: { expired_coinpay_invoice_id, expired_at, ... } }"
    Note over Route: Compute existingMetadata (guard against null/array)
    Route->>CP: createPayment(...)
    CP-->>Route: "{ payment_id, address, amount_crypto, expires_at, ... }"
    Note over Route: Merge: { ...existingMetadata, payment_address, amount_crypto, expires_at, ... }
    Route->>DB: "UPDATE { payout_status, coinpay_invoice_id, pay_url, metadata: merged }"
    DB-->>Route: "{ error: null }"
    Route-->>Client: "200 { data: { payment_address, ... } }"

Loading

_{Reviews (1): Last reviewed commit: "Preserve bounty payout metadata" | Re-trigger Greptile}

[greptile-apps]

The regression fixture only contains non-conflicting metadata keys (expired_coinpay_invoice_id, expired_at, reviewer_note_id). The PR description states "new payment details take precedence," but no assertion verifies that a stale payment_address or expires_at carried in existingMetadata is actually overridden by the new payment values. Adding one conflicting key (e.g., an old payment_address) would make this guarantee explicit and guard against future refactors that accidentally flip the spread order.

Suggested change

	metadata: {
	expired_coinpay_invoice_id: "cp-pay-expired-1",
	expired_at: "2026-05-22T12:00:00Z",
	reviewer_note_id: "review-note-1",
	},
	metadata: {
	expired_coinpay_invoice_id: "cp-pay-expired-1",
	expired_at: "2026-05-22T12:00:00Z",
	reviewer_note_id: "review-note-1",
	// Stale payment field from the previous invoice — should be overridden
	payment_address: "stale-address-should-be-overridden",
	},