pub fn map_order_error(
error: Error,
instrument: &InstrumentNameExchange,
) -> UnindexedOrderErrorExpand description
Maps an SDK error from placing or cancelling an order to UnindexedOrderError, by whether
Hyperliquid may have acted on the request.
The SDK reports whatever goes wrong once the request is signed as one variant,
Error::JsonParse, holding the underlying error’s
text: a failure to send the request or to read the answer, an HTTP 4xx or 5xx, and an answer
that does not parse. So its text decides:
- An HTTP 4xx is a refusal. The request was turned away: Hyperliquid answers an
/exchangerequest it acts on with 200, refusals included. This rests on the venue’s behaviour; a proxy in between that forwarded the request and then answered 4xx would be misread. A 429 isApiError::RateLimit; any other 4xx is classified as below. - Anything else in
JsonParseisOrderError::Connectivity: the request may have reached the venue, so its outcome is unknown, and the engine looks an open up by its client order id.JsonParsealso covers encoding and building the request before the send, which the requests this client builds do not fail; if one did, the lookups would find the order never placed.
Every other variant fails before the request is sent (an asset the SDK does not list, signing, a number it cannot encode, …), so it is a refusal too.
A refusal naming an unknown instrument is ApiError::InstrumentInvalid. Any other is
classified by its text, as a refusal in a placement response is, so a shortfall of funds is
ApiError::BalanceInsufficient. A cancel never fails for want of funds, so it shares the
classifier harmlessly.