Reconciling a Stellar submission after a client timeout
The client lost its HTTP connection just after it submitted a signed envelope. The transaction hash gives a recovery worker a way to check what happened without creating a second payment.
Poll using the hash of the original transaction
Set TX_HASH to the transaction hash recorded by the submitter and STELLAR_RPC to the RPC URL on that network. This shell pipeline uses jq to encode the parameter. Look under result.status only after checking that the JSON-RPC response did not return an error.
jq -n --arg h "$TX_HASH" '{jsonrpc:"2.0",id:1,method:"getTransaction",params:{hash:$h}}' |
curl -sS -H 'Content-Type: application/json' --data-binary @- "$STELLAR_RPC"
Keep an unknown outcome open
For SUCCESS or FAILED, record the ledger and the returned execution result alongside the original hash. On NOT_FOUND, check the reported oldest and latest ledger against the period in which the transaction could have landed. A recent submission may still be pending. A much older one may have fallen out of the lookup window. Use retained history to reconcile the latter before deciding whether a new payment is necessary. Counting a network timeout as a failure would erase that distinction.