During Shellnet 4.0.30 testing with dexdo-cli v0.0.18 we observed intermittent failures after BUY attempts. Order #113 was consumed by another buyer before our model-only BUY attached, resulting in opened=false and subsequent inference requests returning HTTP 503 with an empty body. A later SELL (order #140, qwen--qwen3.6--27b, 8 ticks × 1 SHELL) was created successfully and remained seller_ready, but BUY attempts either expired without handover or again returned an empty HTTP 503. In every failed case buyer_locked=0, deposit=0, lockedInOrders=none and no funds were lost, so cleanup worked correctly. In the same testing session we also completed multiple successful end-to-end transactions (orders #1, #3 and #5): SELL → BUY → MATCH → HANDOVER → INFERENCE HTTP 200 → streamStop → settlement → seller payout, confirming that the environment was otherwise healthy. The remaining issue is observability: an empty HTTP 503 provides no indication whether the failure was caused by a concurrent buyer consuming the order, a stale ask, seller unavailability, gateway readiness, or a handover timeout. Returning a structured error (for example: token_contract_already_consumed, seller_unavailable, handover_timeout, gateway_not_ready or stale_ask) would make debugging and automated recovery much easier.
During Shellnet 4.0.30 testing with dexdo-cli v0.0.18 we observed intermittent failures after BUY attempts. Order #113 was consumed by another buyer before our model-only BUY attached, resulting in opened=false and subsequent inference requests returning HTTP 503 with an empty body. A later SELL (order #140, qwen--qwen3.6--27b, 8 ticks × 1 SHELL) was created successfully and remained seller_ready, but BUY attempts either expired without handover or again returned an empty HTTP 503. In every failed case buyer_locked=0, deposit=0, lockedInOrders=none and no funds were lost, so cleanup worked correctly. In the same testing session we also completed multiple successful end-to-end transactions (orders #1, #3 and #5): SELL → BUY → MATCH → HANDOVER → INFERENCE HTTP 200 → streamStop → settlement → seller payout, confirming that the environment was otherwise healthy. The remaining issue is observability: an empty HTTP 503 provides no indication whether the failure was caused by a concurrent buyer consuming the order, a stale ask, seller unavailability, gateway readiness, or a handover timeout. Returning a structured error (for example: token_contract_already_consumed, seller_unavailable, handover_timeout, gateway_not_ready or stale_ask) would make debugging and automated recovery much easier.