orders cancel / destroy both fail on a plain unmatched resting offer (possible regression of #54, reproduces unchanged on v0.0.14)

[kevinushana]

Summary

Both documented cleanup paths for an unmatched, never-opened resting sell offer fail — dexdo orders cancel <ID> and dexdo destroy — on a deal with zero funds at risk (funded=false, opened=false, deposit=0). No working CLI method currently retires a stale-but-otherwise-healthy resting offer.

This looks like a regression of (or incomplete fix for) #54, where @Futurizt noted: "v0.0.12 reads orders/market indexer-first (no more long chain-read timeouts) and skips consumed/stale orders instead of blocking on them... please reopen if the symptom recurs on v0.0.12." It has recurred, and reproduces unchanged on v0.0.14 too.

Environment

• dexdo versions tested: 0.0.12 (SHA256-verified against release SHA256SUMS) and 0.0.14 (fresh download, checksum-verified, correctly self-reports dexdo 0.0.14)
• Network: Shellnet, post the 2026-07-17 restart
• OS: Windows 11

Bug 1 — orders cancel/orders list: malformed GraphQL query, broken fallback

dexdo orders --note-addr 0:<SELLER_NOTE> --note-key note.secret.hex --market market.json --contracts contracts/deployed.shellnet.json cancel <ORDER_ID>

WARN dexdo::cli::orders: order-book event fold unavailable; using legacy chain fallback error=account 0:<ORDER_BOOK_ADDR> 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

The event-fold read sends the order-book account_id to GraphQL still carrying its 0: prefix, which the endpoint rejects. It falls back to a "legacy" path that itself hangs — reproduced identically at 30s and 60s timeouts, ruling out a plain slow-network explanation.

Bug 2 — destroy on an unmatched (!_opened) TC: exit_code=336 (iob::ERR_EXPIRED)

dexdo destroy --note-addr 0:<SELLER_NOTE> --note-key note.secret.hex --token-contract 0:<TC> --contracts contracts/deployed.shellnet.json

Error: block manager rejected message code=TVM_ERROR message="Failed to execute the message. Error occurred during the compute phase."; exit_code=336 (iob::ERR_EXPIRED) stage=data

Reproduced twice on v0.0.12, once more on v0.0.14. TokenContract.destroy() (read from the gosh-sh/dexdo contracts source) is a pure local operation — !_opened && !_disputed check, optional buyer refund, selfdestruct — with no call into InferenceOrderBook at all. Exit 336 is defined nowhere in the contracts tree except as InferenceOrderBook.ERR_EXPIRED, so this may be a message-envelope-level expiry rejection (plausible given intermittent shellnet RPC instability) rather than an actual IOB interaction — but either way it blocks the only remaining path to retire a stale offer.

Impact

No CLI-only way currently exists to retire a plain unmatched resting offer with zero funds at risk — both documented routes (dexdo-sell-model skill guide) fail. Contributes to the same order-book congestion class as #36/#54.

Ask

1. Is this the same code path DexDo CLI Bug Report: Direct Chain Reads Timeout and Stale Order Blocks Buyer Matching #54 targeted, or a separate regression?
2. Any workaround to retire a zero-risk resting offer in the meantime?

[kevinushana]

Follow-up: the same root cause (order-book account_id sent to GraphQL with its 0: prefix still attached, rejected as Invalid account_id: expected 64 hex characters without prefix) also hits dexdo market <model> and dexdo executable-book <model> — not just orders cancel/orders list. Both fail identically with the same WARN line followed by Error: chain read timed out after 30s; retry or use dexdo market-data where applicable, on the same account. Scope is broader than the original report — any command going through the "order-book event fold" read path is affected, with dexdo market-data depth (indexer-backed) as the only currently-working alternative for reading a book.

[Futurizt]

Confirmed — on an unmatched, never-opened resting offer (funded=false, opened=false, deposit=0, zero funds at risk) neither dexdo orders cancel <ID> nor dexdo destroy currently retires it, so there is no working CLI path to clear a stale-but-healthy resting offer. This is a real cleanup-path gap (adjacent to the stale-liquidity/stream-lock cleanup work); tracking a fix so an unmatched resting offer can be cancelled/destroyed with no funds at risk. Thanks for the clean repro.

[latcomblockchain]

Retested on v0.0.15 (release binary, shellnet 4.0.27, macOS, 2026-07-22): both halves now work.

• orders ... cancel 531 on a plain resting unmatched offer (order_id=531, shared book 0:08a99e72..., TC 0:f2ea2924...) -> cancel submitted ... order_id=531, exit 0; follow-up orders list shows none=true — the order is really gone on-chain.
• destroy on that same never-matched, placed TC also worked: submitted, and the account now reads state=closed active=false.

Looks fixed in v0.0.15 from where I sit; leaving open for the owner to confirm/close.

[Futurizt]

Verified FIXED in v0.0.15 (https://github.com/gosh-sh/dexdo-cli/releases/tag/v0.0.15): the reporter retested v0.0.15 and confirmed orders cancel/destroy on an unmatched resting order now work. Closing.