`dexdo close` refuses the stop path its own `status` recommends: `INTERNAL / internal invariant failed` on an `incompatible prior ProbeBurned receipt`

[tbuza]

Version: v0.2.0 · mainnet, generation 4.0.36 · x86_64 Linux · seller role

A seller cannot exit a deal whose buyer has stopped consuming. status names dexdo close as the
stop action; close then refuses it, and classifies the refusal as its own internal invariant
failure. Three independent deals, on three different books, fail identically.

What status says to do

$ dexdo --data-dir ~/.dexdo status 894e6f47…::894e6f47…
status … state=streaming active=true funded=true opened=true disputed=false probe_accepted=true
context … model=Qwen3.6-27B
accounting finalized_owed=1 buyer_locked=3.025 deposit=1.025 buyer_bond=2
           tokens_final=1000000 tokens_pending=1000000
           probe_time=1788663478 last_claim_time=1788663673
next=seller_claim_finalize_or_settle_week_or_seller_stop
  stop_action=run `dexdo close` on 'deal-0-894e6f47…-seller', with the seller --note-key to sign
  stop_effect=TokenContract.sellerStop(); buyer may STOP when done

What close does

$ dexdo --data-dir ~/.dexdo --non-interactive close deal-0-fb855871…-seller --json
{"schema":"dexdo.error.v1","operation":"close","code":"INTERNAL",
 "message":"internal invariant failed",
 "cause":"TokenContract fb855871…::fb855871… action seller_stop has incompatible prior ProbeBurned
          receipt message_id=1ec708c38e9203602e8e10b8f398c890359ca15799b9f7dc1bc2947c435be3c5
          created_at=1788599128; refusing before any money POST",
 "retryable":false}

Same failure on all three of our open deals, different books, different buyers, different days:

deal	book	ProbeBurned receipt created_at
fb855871…	Qwen3.8-27B	1788599128
deff9230…	gpt-oss-20b	1788590514
894e6f47…	Qwen3.6-27B	1788597380

Every one is state=streaming, probe_accepted=true, disputed=false. Nothing unusual happened to
them: each was matched, delivered its probe tick plus one more, and the buyer then went quiet.

withdraw-shell works fine on the same TokenContracts — we withdrew the finalized 1 SHELL from
each while close was refusing — so the deals are reachable, signable and healthy. It is
specifically the seller_stop action that the receipt check rejects.

Why it matters

max_open_deals is 1, so an open deal means no resting ask on that book. A buyer who opens a
deal, consumes two ticks and disappears therefore takes that seller off the market indefinitely,
and the documented way out is refused. Our three busiest gateways have been unable to list for over
a day; the books they serve went from ~365 SHELL of daily volume to two fills.

There is no other seller-side exit: destroy requires the deal to be STOPped, which is what close
was going to do, and recover/reclaim are buyer-signed.

Notes

• code: INTERNAL and message: internal invariant failed are the client's own classification, so
  this looks like a receipt-compatibility check comparing seller_stop against a stored
  ProbeBurned receipt for the same TokenContract and treating a different action as a conflicting
  replay, rather than a state the operator can fix.
• close --json must be written as close --json; --json close is rejected. Minor, but the tip
  text (tip: 'close --json' exists) is what pointed the way.
• If refusing is correct here, status's stop_action should not name a command that cannot run,
  and the error should say what the operator is expected to do instead.

[Pithung]

Same three deals are also stuck from the buyer side (this issue shares a root cause with #147 and #148).

I am the buyer on the exact TokenContracts listed in the table above. Cross-referencing:

TokenContract	#152 (seller @tbuza)	#147 (me, buyer)
0:fb855871…	close -> INTERNAL / incompatible prior ProbeBurned	close/recover -> prior beneficiary mismatch, refused
0:deff9230…	close -> INTERNAL / incompatible prior ProbeBurned	close/recover -> prior beneficiary mismatch, refused
0:894e6f47…	close -> INTERNAL / incompatible prior ProbeBurned	close/recover -> prior beneficiary mismatch, refused

The same pairing exists for 0:17b2d080…: I am its buyer (#147, first example), and @Juanant2804 is its seller (#148, nonce 2026090504). Both of us are refused on it too.

So on all four deals, neither party can stop or close the deal:

• buyer path (close/recover, Cannot close OPEN deal after TC address recycled — prior StreamStopped beneficiary mismatch #147): prior terminal receipt beneficiary … does not match local buyer note …; refusing local reconciliation
• seller path (close, Seller deal stuck #148/dexdo close refuses the stop path its own status recommends: INTERNAL / internal invariant failed on an incompatible prior ProbeBurned receipt #152): either seller_stop is already recorded by exact StreamStopped receipt (no-op refusal) or action seller_stop has incompatible prior ProbeBurned receipt.

Chain evidence I pulled today for the three #152 deals (settlement-receipt --json 0:fb855871…/0:deff9230…/0:894e6f47…, mainnet 4.0.36):

• all three: state=funded=true opened=true probe_accepted=true disputed=false
• terminal.status = not_final and consistency_issues = [] — the receipt, scoped to the current lifecycle, sees no conflict at all
• the finalized tick was already paid out: ShellWithdrawn 1 SHELL to the seller note succeeded on each deal (matches the "withdraw-shell works fine" note above)
• the account is active, signable, and healthy; only the STOP action is refused.

The receipt guards on both sides are scanning the full historical event set of the address, which includes receipts from the previous deal lifecycle on the same recycled deterministic TC address. That is the same root cause behind all three issues: the terminal-receipt check must be scoped to the current lifecycle (e.g. only events after the latest ContractDeployed), otherwise a destroyed earlier deal on the same address permanently blocks the live deal from both directions.

Would a fix that scopes the "already terminal / prior receipt" guards to the current lifecycle (post-latest-ContractDeployed) resolve all three? Happy to provide full --raw receipts for any of the four contracts.

[tbuza]

Confirming @Pithung's root cause from the seller side, with a reproducible case: the same nonce was issued twice on this note, so the deterministic TokenContract address really was recycled between two different deals.

Deal addresses derive from note+nonce, and our supervisor draws nonces from a counter that was reset at some point. Scanning every market manifest this note has ever written:

nonce 210 -> tc 0:deff9230b9ba…   data-dir .dexdo2   model gpt-oss-20b   price 1
nonce 210 -> tc 0:deff9230b9ba…   data-dir .dexdo4   model Qwen3.6-27B   price 3

0:deff9230… is one of the three deals in the table above. It was provisioned twice, under two different models, at the same address — so the live deal is sitting on top of a destroyed earlier deal's receipts, exactly as described.

It reproduced again today while this issue was open:

nonce 906 -> tc 0:2f06463bd139…   .dexdo6   Qwen3.6-27B   price 15
nonce 906 -> tc 0:2f06463bd139…   .dexdo7   gpt-oss-20b   price 2

The second seller refused to start:

Error: startup TokenContract 0:2f06463bd139… is for model Qwen3.6-27B
       (0x7f7b3e641f3606b5c18dbd3f4a65aac0615f254ccf716797892720408d879bad),
       not requested model gpt-oss-20b
       (0xca1fe4e9c1499d821397771bdaee427be3244b55371a3803b12152c46dc44a28)

That refusal is the client working correctly — it noticed the address already belonged to another model. The receipt guards in close do not make the same distinction; they see the union of both lifecycles.

Two observations that may help scope the fix:

1. A never-before-used nonce is unaffected. The deal at nonce 906's first use has been matching, delivering and settling normally all morning on the same note, same client, same manifest — including a fill at 15 SHELL/tick. Only the addresses with a prior lifecycle are frozen. That is consistent with lifecycle-scoped guards being the fix, and it gives operators a workaround in the meantime: never reuse a nonce; keep a monotonic counter above all history.

2. The client already knows where the boundary is. The model-identity check at seller startup distinguishes the current deal from the prior one at the same address. Whatever that check uses to decide "this address currently belongs to deal X" is presumably what the terminal-receipt guards need too.

So yes — scoping the "already terminal / prior receipt" guards to events after the latest ContractDeployed would resolve this from the seller side, on all three of the deals listed above. Happy to run any diagnostic against these three; they are still open and reproducing.

One smaller thing while it is being looked at: status prints stop_action=run dexdo close … for these deals, and close then refuses. Whatever the guard ends up doing, status should not recommend a command that cannot execute.