Draft
Conversation
Documents how to debug why a batch of orders failed to execute or executed
slowly. Companion to the single-order and quote-verification skills; aimed
at the case where you receive a CSV of order UIDs and want a per-order
classification plus per-quoter aggregates.
Per order, the skill produces:
order_id, expired, expired_detail, quoter, quoter_name,
did_bid, bid_layer, discard_reason
The seven-step procedure:
1. Bulk-fetch order details from the orderbook API (status, quote.solver,
validTo). Old orders that 404 are recorded as `unknown` rather than
silently dropped.
2. Per-order lifecycle from `debug.cow.fi/api/orders/{uid}/events` —
the last `OrderEventLabel` deterministically classifies an order as
expired-at-validTo vs removed-early (invalid / filtered / cancelled /
never-qualified).
3. Solver address ↔ name (and URL) mapping from autopilot's `Creating
solver` log.
4. Autopilot `proposed solution` per quoter (OR-batched ≤30 UIDs per
query — backtick-escape `parsed.spans./solve.solver`).
5. Driver-side `discarded solution: settlement encoding` for in-cluster
solvers, with `parsed.fields.err` bucketed into solver-account-out-of-gas,
simulation revert, simulation OOG, signature/permit failure.
6. Combine into a CSV; merge `proposed`/`discarded` sets so the same order
can show `bid_layer = both` when multiple solutions for the same order
land on different sides.
7. Per-quoter summary table + dominant-root-cause paragraph.
Co-location is detected purely from logs (no infra-repo access required):
the autopilot's `Creating solver` log carries each solver's URL, and a
host suffix of `.svc.cluster.local` indicates an in-cluster solver whose
driver logs are queryable. A driver-pod log-presence stats query is the
fallback / cross-check — zero hits ⇒ assume co-located, regardless of URL.
Co-located solvers are opaque to us: `did_bid` becomes `unknown`, never
`no`, when only autopilot-side data is available.
Caveats called out: log retention windows, OR-chunk sizing and the
backticks-vs-quotes pitfall on slash-containing field paths, the
`parsed.fields.orders` debug-string format that needs regex extraction,
and the fact that solvers can be promoted/demoted between deploys (pull
`Creating solver` for a window overlapping the orders' time range, not
"now"). A pre-canned query reference at the end covers the common
follow-ups (any-bidder-on-order, risk-detector exclusion).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Documents how to debug why a batch of orders failed to execute or executed slowly.
Changes
Skill file added
How to test
Note that for large files this skill may use significant credits