A supplier feed repeats one key with different prices: reject the conflict before updating

Group before applying

Group rows by the agreed supplier-plus-SKU key. In this example, an exact duplicate of the agreed business fields can be reported and collapsed, while any price or quantity disagreement holds the entire feed for review. That is an authored policy, not a universal supplier rule. Row position alone is not a credible effective date.

• Define which fields make two rows equivalent.
• Keep conflicting synthetic values and the source row numbers in the exception report.
• Do not silently use the first or last row unless that precedence is part of the source contract.

Upsert is not conflict adjudication

PostgreSQL documents a cardinality violation if one ON CONFLICT DO UPDATE command affects the same existing row more than once. UPDATE FROM has another trap: multiple matching source rows can produce an unpredictable chosen update. Neither statement decides which price the supplier intended. Validate the source group before a write and record its disposition.

• A unique target key does not itself validate duplicate input rows.
• Do not weaken constraints to make a problematic batch pass.

Test independence from file order

Use two equal synthetic rows, then two rows with the same key and different prices. Reversing their order must not turn a held conflict into a successful update. The example disposition matrix holds conflicting batches before any target change; it does not replay or repair historical imports.

• Check the exception identifies the conflicting key and values without exposing private payloads.
• Document whether an identical duplicate is a warning or a rejection in the buyer's actual policy.

Priced enquiry and non-fit

One existing, deterministic duplicate-selection defect may fit the local regression-test repair, from £295 after bounded reproduction and a fixed quote. A new feed-validation workflow or broad database redesign is not automatically a bug repair. If the conflict policy is undecided, the purchasing owner must settle it first. Initial inputs are invented duplicate rows, the expected disposition and the application stack, not a real price list or database credentials. Production reconciliation and deployment are excluded; the proposed price is untested and payment follows agreed checks and sign-off.