test(seller): pin the award-dedup contract on two distinct award events (#279)

[orveth]

Tests only — no production code changes. Pins the seller's award-dedup contract and files the hole in it as #279.

What the two legs are for

The seller dedups awards on two different keys, and the shapes they catch are not the same shape:

• award record keys on event id (awards.award_id PK) ⇒ catches a re-seen award id (relay redelivery).
• execute guard keys on job state (Delivered/Paid/Failed ⇒ skip) ⇒ catches a redundant award for a terminal job.

A buyer retry produces neither: a fresh event id for a job we already hold. So covering redelivery says nothing about retries, and the two legs test that boundary from both sides. Both outcomes were declared before either test was written, so neither could be retrofitted.

Leg 1 — a_fresh_award_id_for_a_delivered_job_is_recorded_but_never_re_executed (green)

Two distinct award ids, one job id, job Delivered. Asserts the composition, not the predicate alone:

1. re-seen id ⇒ Awarded::Duplicate (the contrast case, so both keys are distinguished in one place)
2. fresh id ⇒ Awarded::New — the record layer does not catch a retry
3. the job row still reads Delivered — the re-attempt does not clobber terminal state
4. therefore the state guard is what refuses the second run

Step 2 is the point. Asserting only the predicate leaves the record layer's answer unstated, and that answer is what decides whether the guard is load-bearing at all.

This is not already covered. resume_selects_awarded_or_executing_not_delivered_or_terminal tests the pure predicate. delivered_or_paid_job_is_not_re_executed asserts "a delivered job must not re-execute on a duplicate award" — but it never records a second award; it drives one award to Delivered and checks the predicate. That message named a property the test did not construct, so this PR corrects it to say what it actually asserts and leg 1 carries the duplicate-award claim.

Red-proven. Changing the award path's INSERT OR IGNORE INTO jobs to an upsert that writes state = 'awarded' fails leg 1 on exactly the intended line:

assertion `left == right` failed: a second award must never clobber a terminal job state back to awarded
  left: Some(Awarded)
 right: Some(Delivered)

Leg 2 stayed green under that break, correctly — it does not depend on terminal state.

Leg 2 — mid_flight_second_award_is_admitted_for_execution_no_per_job_in_flight_lock (#279)

Same shape, but the job is awarded/executing (both are exercised). The record layer says New, the guard says proceed, and nothing between them refuses — so a second execute_job is admitted for a job already running.

⚠ This test passing is the bad news. It is a tripwire: it asserts the unguarded behaviour and goes red the moment the per-job in-flight lock lands, at which point the fixer inverts one assertion and closes #279. The doc comment says so in place.

Why a tripwire and not #[ignore]: an ignored test reports nothing whether the hole is open or closed — the failure mode is silence, which is the class of defect this lane has spent the day removing. The hazard is real and worth naming: CI now enforces a known-wrong behaviour, so anyone who fixes the hole sees a red test. That is intentional and the comment routes them, but reviewers should agree it is the right trade before merging.

What #279 costs — and does not

Not double payment; that is blocked further down (reservation PK, single job-keyed watcher, outbox dedup) — verified by the mobee lead, not by this PR. The costs are a duplicate agent process, a slot-accounting bypass (the first award already removed the parked permit, so the second execution holds no permit and the node exceeds its configured concurrency invisibly), and a second push that can move the branch tip off the journaled commit — which the buyer refuses on tip-match, failing toward not paying a seller that did the work.

⚠ There is no observed field instance. This is a code fact from reading both dedup paths; an earlier "second award event" in this fleet turned out to be an accept event and that attribution was retracted.

Verification

• Both legs green: 3 passed including the neighbour, run under the money-path feature set (--no-default-features --features gateway,git-delivery,wallet).
• Count prediction, so the money-path row's jump is expected rather than anomalous: dev is currently 639 passed; 2 ignored (641). This PR adds 2 ⇒ the row should read 641 passed; 2 ignored (643 total). cargo test --lib -- --list reports 643 on this branch and both new tests appear by name in it, so they are genuinely in the suite CI runs — not compiled out.
• Branched off dev after ci: run the money-path suite in its own job (#271) #276, so these run inside the new money-path job.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mobee	Ready	Preview	Jul 30, 2026 12:17am