Skip to main content

Troubleshooting

Use this page when SDK v1 reads or writes do not behave the way you expect. Most production issues fall into one of five buckets: missing receipt handling, stale follow-up reads, duplicate submits, transport failures, or workflow assumptions that belong to SDK v2 or GraphQL instead.

The SDK returned a transaction hash, but my UI is still pending​

That is expected. SDK v1 order methods submit the transaction and return the hash. They do not wait for the receipt for you.

Recommended pattern:

  1. Persist the transaction hash as soon as you receive it.
  2. Wait for the receipt with sdk.publicClient.waitForTransactionReceipt.
  3. Only after the receipt succeeds should you start polling positions, orders, or trade history.

If the client reloads before confirmation, recover from the saved transaction hash instead of resubmitting.

The transaction succeeded, but the order or position is not visible yet​

Treat follow-up reads as eventually consistent.

  • Transaction inclusion, order creation, keeper execution, and indexed history do not complete at the same time.
  • orders.getOrders() shows active on-chain orders, but trade history comes from Subsquid and can lag behind live chain state.
  • If you need a coherent account snapshot, refresh one marketsInfoData and tokensData snapshot and reuse it across position and order reads.

I accidentally submitted the same action twice​

SDK v1 does not support idempotency keys or client order IDs.

Recommended client behavior:

  1. Disable repeat submit actions while a transaction is pending.
  2. Persist the last in-flight transaction hash per user action.
  3. Require an explicit retry action after a failure instead of auto-resubmitting writes.

Cancel or replace shows unexpected order state​

This is usually a race between an old UI snapshot and current on-chain order keys.

  • Refetch active orders immediately before calling cancelOrders.
  • Cancel by the latest on-chain order keys, not by cached UI state from an earlier poll.
  • After cancel or replace, refetch orders again instead of assuming the previous list is still valid.

Read calls fail with timeouts or transient RPC errors​

The default SDK-created viem transports set retryCount: 0, and SDK multicalls use a 40000 ms timeout.

Recommended client behavior:

  1. Add retry and backoff around safe read paths.
  2. Keep write submission separate from read retries so you do not duplicate transactions.
  3. Consider supplying your own viem clients if you need a custom transport strategy.

A limit order did not simulate before submit​

That can be current behavior, not necessarily a bug.

  • Market increases simulate by default unless you opt out.
  • Limit increases skip simulation in the current implementation.
  • Market swaps simulate by default, while Limit Swap orders do not.
  • createDecreaseOrder() currently skips simulation.

If your UI exposes these flows, validate inputs before submission and surface chain-level errors clearly.

Next steps​