Recover a lost PancakeSwap X submit response

Save the X order hash before submitting the signed candidate. If the submission response disappears, that hash gives the application a recovery handle without constructing another order.

PancakeSwap's example explicitly uses the pre-known order hash for reconciliation. Its status endpoint belongs to X orders; ordinary aggregator transactions are tracked through RPC instead.

Use bounded status recovery

After a lost submit response, query status for the original chain and order hash. A brief not-found response immediately after submission can reflect propagation. Retry within a bounded policy while preserving the unknown-outcome state.

Do not interpret every 404 as success, and do not retry forever. If the order remains absent, inspect the original submission error and relevant deadlines. A new quote may eventually be appropriate, but only after the application has accounted for the possibility that the original order was accepted.

Handle terminal states distinctly

A filled order needs settlement transaction reconciliation. An expired order did not reach a fill before its deadline. A cancelled order reached the service's cancellation state. Preserve the status evidence and stop the ordinary polling loop at a documented terminal state.

Save both the order hash and any later transaction hash. A page reload should resume status checking without requiring another signature.

A targeted test

Mock a successful server-side submit with a dropped HTTP response, two temporary not-found status results and then an open order. Verify that only one order was signed and submitted as a new economic intent. Continue to a filled status and assert that the tracker transitions to the actual transaction rather than treating the order identifier as a receipt hash.