buyer --local-listen: real inference never reaches the consumer despite successful match+handover, on both v0.0.12 and v0.0.14

[kevinushana]

On shellnet (real chain, real notes), dexdo buyer --token-contract <TC> --local-listen 127.0.0.1:<port> --allow-unverified-model ... consistently matches, escrows, and receives handover successfully, but a /v1/chat/completions request against the resulting --local-listen endpoint never returns real inference content — the failure mode differs by version:

v0.0.12 (2/2 reproductions): request rejected near-instantly (~0.001s) with HTTP 410 {"error":{"message":"deal session closed; open a new session","type":"invalid_request_error"}}, even when fired immediately on endpoint_ready and even though the buyer process/port were confirmed still alive.

v0.0.14 (2/2 reproductions, against two independent non-self counterparties — order #302 and #303, different sellers): request hangs, then fails after consistent ~133–136s with HTTP 502 {"error":{"message":"upstream open failed after retry: transport error","type":"invalid_request_error"}}.

Repro steps:

1. dexdo buyer --note-addr <note> --note-key <key> --frame-model qwen--qwen3--32b --token-contract <non-self TC> --ticks 100 --max-price-per-tick 10 --allow-unverified-model --local-listen 127.0.0.1:<port> --contracts <manifest> --json
2. Wait for endpoint_ready in the JSONL event stream
3. curl <base_url>/v1/chat/completions -d '{"model":"qwen--qwen3--32b","messages":[{"role":"user","content":"..."}],"max_tokens":10}'
4. v0.0.12 → immediate 410; v0.0.14 → 502 after ~134s

No funds lost — escrow settles normally in all cases. But across 4 independent repro attempts (2 per version, against 3 distinct non-self sellers total), we have never once received actual inference output through --local-listen on real shellnet. This blocks confirming that paid-for inference is retrievable at all.

[kevinushana]

Additional independent evidence, from the seller side this time — a genuine third-party buyer, not our own client.

Two of our resting offers were matched by real external buyers today. Both reached a full open() successfully — confirmed directly in the seller process logs:

seller_match_opened token_contract=0:7f85021f...
stream open; serving until shutdown

seller_match_opened token_contract=0:63c95ed4...
stream open; serving until shutdown

Some time later, dexdo status on both shows the deal fully closed with all escrow zeroed:

state=funded-but-never-opened active=true funded=true opened=false probe_accepted=false
accounting finalized_owed=0 buyer_locked=0 deposit=0 prepaid=0 frozen=0

Reading TokenContract.sol's stop() (the buyer-only exit function) explains this exactly: when !_probeAccepted, stop() burns the probe tick + seller's commission, refunds the remainder to the buyer, and sets _opened = false. So this is the contract behaving correctly — the buyer opened the stream, never accepted the probe (i.e., never got usable content out of it), and their own client called stop() to cleanly exit.

The significant part: this is an independent, real, external buyer — not us — hitting the identical "opens successfully, but no real inference is ever consumed" pattern documented in the rest of this issue from our own buyer-side testing. Two separate counterparties, two separate deals, same outcome. This rules out the possibility that it's something specific to our own client/test harness.

Two small, separate CLI-accuracy notes noticed along the way (not the main point, just mentioning in case useful):

• dexdo status's state=funded-but-never-opened label is misleading for this case — the deal clearly did open (per the seller log) before closing; the label conflates "currently not open" with "never opened."
• The printed next=buyer_cleanup_after_timeout hint on an already-closed deal is stale/inapplicable guidance.

[AndreaMangraviti]

Independent reproduction on live Shellnet with dexdo v0.0.14

I can independently confirm the same post-handover failure class on a fresh, explicitly targeted third-party ask.

Environment

• OS: Windows
• Network: Shellnet
• dexdo: v0.0.14
• SuperRoot / RootPN / RootOracle: 4.0.27
• dexdo doctor: PASS
• Shellnet endpoint: reachable
• PrivateNote code hash: PASS
• Policy: OK
• Buyer note: current-generation, funded, with lockedInOrders: none before the test
• Continuity mode: on-demand
• Model verification: name-only via --allow-unverified-model

Selected offer

• frame_model: qwen--qwen3--32b-mock-main-9
• order_book: 0:996a71d728a1d74ef33230994db891592dd79569bccdaed4d6043879a7584d0f
• order_id: 1
• token_contract: 0:d2ecefe63c902b52302bfca7c228626ebe26c3bd02af1bd822a2915f07edbd79
• ticks: 8
• price_per_tick: 10
• total_with_fee / escrow: 80

Immediately before submission, an explicit status check showed:

• state: placed
• active: true
• funded: false
• opened: false
• buyer_locked: 0

The offer was therefore still resting and unfunded at the final buyer preflight.

Buyer invocation pattern

dexdo buyer --note-key <REDACTED> --note-addr <CURRENT_GENERATION_BUYER_NOTE> --frame-model qwen--qwen3--32b-mock-main-9 --token-contract 0:d2ecefe63c902b52302bfca7c228626ebe26c3bd02af1bd822a2915f07edbd79 --allow-unverified-model --models <NAME_ONLY_MODELS_JSON> --continuity-mode on-demand --ticks 8 --max-price-per-tick 10 --local-listen 127.0.0.1:18081 --contracts contracts/deployed.shellnet.json --json

Observed buyer event sequence

The buyer successfully progressed through the complete purchase and handover boundary:

1. endpoint_binding
2. endpoint_ready
3. quote_selected
4. buy_submitted
5. matched
6. handover_waiting
7. handover_received

Relevant values:

• quote_complete=true
• reconciled_ambiguous_submit=false
• order_book=explicit_token_contract
• handover anchor: {"kind":"token_contract_state","value":"handover_present"}

A live status read after handover showed:

• state: probe
• funded: true
• opened: true
• buyer_locked: 80
• deposit: 70
• frozen: 10
• probe_accepted: false

This confirms that quote selection, escrow submission, matching, seller open and handover all succeeded.

Consumer API failure

The request to the local OpenAI-compatible endpoint did not return inference.

The first /v1/chat/completions attempt timed out after 90 seconds. The buyer runtime logged:

consumer API: upstream open failed; retrying once per dead_gateway=retry_then_reclaim
error=transport error

The retry then returned:

HTTP 410

Response:

{"error":{"message":"deal session closed; open a new session","type":"invalid_request_error"}}

No inference payload was received and the probe was never accepted.

Recovery and final accounting

The buyer subsequently submitted streamStop. Buyer-side funds were released successfully.

Final accounting:

• buyer_locked: 0
• deposit: 0
• prepaid: 0
• frozen: 0
• finalized_owed: 0
• PrivateNote lockedInOrders: none reported
• PrivateNote private balance remained 10000.000000000 SHELL

The remaining TokenContract status is:

• state: funded-but-never-opened
• active: true
• funded: true
• opened: false
• probe_accepted: false

This final label appears misleading for this lifecycle because the deal was demonstrably opened earlier (opened=true during probe) and handover_received was emitted. It appears to describe the current post-stop flags rather than the historical fact that the stream had opened.

Independent conclusion

This reproduces the same issue reported here:

• explicit fresh TokenContract selected;
• escrow submitted successfully;
• match completed;
• seller opened the deal;
• handover received;
• local consumer endpoint available;
• real inference never delivered;
• upstream transport failed;
• retry returned HTTP 410;
• buyer exited and recovered its funds.

The failure is therefore after the chain purchase/handover boundary and before successful inference consumption. It does not appear to be caused by stale liquidity, model-only order selection, matcher-head drift, insufficient note balance or a local endpoint binding failure.

This also matches the independent seller-side evidence already reported in this issue: a deal can open and later settle with probe_accepted=false because the buyer never receives usable inference.

Could the maintainer confirm whether the HTTP 410 and v0.0.14 HTTP 502 variants are expected to share the same upstream session/gateway lifecycle root cause?

[latcomblockchain]

Adjacent v0.0.15 datapoint to help triage (release binary, shellnet 4.0.27, macOS, 2026-07-22). Deliberately ran the consumer path with an invalid upstream key (so: expected failure, NOT this bug) to map the failure surface:

• match + handover + endpoint_ready all fine; curl /v1/chat/completions returned in 0.7 s with HTTP 502: {"error":{"message":"stream error: status: Unavailable, message: \"upstream HTTP 401 Unauthorized\"...","type":"invalid_request_error"}}. So when the seller's upstream call fails outright, the consumer DOES get a prompt, explicit error — no hang, no silent 200.
• Diagnosability gap: the seller logged nothing for that failed upstream call, and the buyer emitted no JSONL event either — the 502 body is the only evidence anywhere.

So if your valid-key runs hang/return nothing instead of an instant 502, the failure is somewhere other than the plain upstream-request path (which fails loudly) — and per the above, seller-side logs won't show it. Hope that narrows it.

[Futurizt]

Update from our side (v0.0.15): we built a cross-party buyer --local-listen live test on shellnet (buyer + a distinct seller/note it does not own, consumer supplies the prompt via curl /v1/chat/completions). On v0.0.15 the delivery works: probeAccepted=true, the consumer receives real streamed tokens, and the deal settles cleanly. We could NOT reproduce the 410/502 you saw on v0.0.12/v0.0.14.

Two possibilities: (1) it's fixed in v0.0.15, or (2) it's specific to the particular external seller you matched (order #302/#303) — something about that counterparty's stream, which our controlled seller doesn't exhibit. Could you retest on v0.0.15 and report? If it still 410/502s, please include the seller's TC/order + the exact endpoint_ready→curl timing so we can chase the specific counterparty behavior. Keeping open pending your retest.