Seller process crashes outright on a transient network reset, and a relaunched-but-still-resting unmatched offer has no resume path (5/5 reproduction)

[kevinushana]

Summary

Two causally-linked bugs that together leave a crashed seller with an unmatched resting offer permanently unrecoverable via a plain restart:

Bug A — seller process crashes outright on a transient connection reset, no retry logic

A plain connection reset while polling shellnet.ackinacki.org (e.g. Error: shellnet: POST https://shellnet.ackinacki.org/graphql: ... connection error: connection reset) kills the entire seller process — no retry, no backoff, no reconnect attempt. Reproduced independently on two different seller processes in the same session, discovered only via manual process-list checks, not any error the tool itself surfaced proactively. The on-chain TC/offer survives untouched; only the local process (and the gateway serving buyers) dies.

Bug B — relaunching against an already-resting, still-unmatched offer has no resume path, crashes deterministically

seller.rs's resume logic only skips re-posting when a TC is already matched (funded-but-never-opened → resumes cleanly as readiness=resumed_funded_tc). An unmatched but already-resting offer (i.e. exactly what Bug A leaves behind) has no equivalent check — every relaunch attempts to re-post the identical offer, which fails with:

Error: shellnet: seller postSellOffer outcome is not yet confirmed for TokenContract 0:<TC>; no placement, match, or returned placement value was observed

Reproduced 5 consecutive times in a row on the same TC — not a transient blip. Checked dexdo seller --help in full: no flag exists to skip the offer-post step on startup.

Environment

• dexdo 0.0.12 (SHA256-verified) and 0.0.14 (fresh download, checksum-verified)
• Network: Shellnet, post the 2026-07-17 restart
• OS: Windows 11

Impact

Once Bug A fires, Bug B means the affected offer can never be cleanly resumed — the only workaround found was provisioning an entirely fresh TC (new --nonce), permanently orphaning the old one. That orphaned TC then also can't be cleaned up (see #69).

Ask

1. Should the resume check in seller.rs also cover "already resting, unmatched" (not just "already matched"), skipping the offer-post and going straight to the match-watch loop?
2. Any interest in basic retry/backoff around the shellnet RPC client for transient connection errors, rather than a hard process exit?

[Futurizt]

Confirmed as a real robustness gap: a transient connection reset while polling shellnet.ackinacki.org should be a retryable transport error, not a hard process exit — the seller poll loop needs bounded retry/backoff on transient chain-transport errors (distinct from a definite/decoded failure). Bug B (a relaunched-but-still-resting unmatched offer has no resume path) is the same missing-cleanup/resume gap tracked in #69. Tracking Bug A (transient-reset retry) as its own robustness fix. Thanks for the 5/5 repro.

[tbuza]

Confirming both facets of this on v0.0.15 / shellnet 4.0.27 (Windows), fresh repro:

1. Crash on transient network reset. A resting, seller_ready seller died outright with:

Error: shellnet: error sending request for url (https://shellnet.ackinacki.org/graphql): client error (SendRequest): connection error: connection reset

No retry/reconnect — the process exits, leaving the offer resting on-chain with no gateway behind it.

2. No resume path for the still-resting offer. Relaunching dexdo seller on the same --market (offer still resting from before the crash) fails:

Error: shellnet: seller postSellOffer outcome is not yet confirmed for TokenContract 0:...; no placement, match, or returned placement value was observed

And the stranded offer can't be cleared either — dexdo orders ... cancel <id> hits the direct-read path and times out:

order-book event fold unavailable; using legacy chain fallback error=account 0:08a9... ext-out GraphQL errors: [{"message":"Invalid account_id: expected 64 hex characters without prefix", ...}]
Error: chain read timed out after 30s; retry or use `dexdo market-data` where applicable

(that GraphQL 0:-prefix bug is #89.)

Net effect: a single network blip strands the deal — the only recovery is dexdo provision --nonce <new> + a fresh offer, orphaning the old resting one (which then just sits in the book until a buyer takes it and reclaims). This makes unattended 24/7 selling impractical without an external supervisor that re-provisions on every restart.

[Futurizt]

Fixed in v0.0.16. The seller now stays alive on transient match-watch transport failures, and a restarted seller resumes one exact resting SELL row without reposting it. The restart path was live-verified through match, handover, two finalized ticks, buyer STOP, and AmicableSplit with no burn.