<p>This occurred because our <code>time_to_live</code> in the transaction was too low. The recommended value in iohk documentation is <code>10</code> which is woefully inadequate. If this is happening to you bump this up. We set ours to <code>300</code> which has been working great.</p>

CC BY-SA 4.0
2021-11-25T01:29:22.560Z
2021-11-25T01:29:22.560Z
melchoir55
<p>We are programatically submitting transactions to the blockchain using <code>cardano-wallet</code>. Everything seems to be fine when we do so. <code>cardano-wallet</code> returns a <code>202</code> indicating success along with a transaction id and everything else you would expect. However, when we go check the blockchain explorer for the tx it isn't there. As you might expect, the chain never reflects the change (customers don't receive what we send them).</p>
<p>The only thing we see in the logs is that sometime after sending the tx the cardano node will provide the <code>TraceMempoolRemoveTxs</code> error. Here is he full line from the node:</p>
<pre><code>cardano-node-1    | [c7e60f27:cardano.node.Mempool:Info:59] [2021-11-24 20:24:55.43 UTC] fromList [(&quot;txs&quot;,Array [Object (fromList [(&quot;txid&quot;,String &quot;txid: TxId {_unTxId = SafeHash \&quot;53625bb985197b9af7e41b12449f70666dcebf8fe9afc65dae29557b31d02d14\&quot;}&quot;)])]),(&quot;mempoolSize&quot;,Object (fromList [(&quot;bytes&quot;,Number 0.0),(&quot;numTxs&quot;,Number 0.0)])),(&quot;kind&quot;,String &quot;TraceMempoolRemoveTxs&quot;)]
</code></pre>
<p>Now, this event occurs more often than not, but it does not always occur. Sometimes our transactions successfully make it through to the blockchain. We can find no clear pattern on when they do or not.</p>
<p>Does anyone know what is happening here or how we can deal with it?</p>

CC BY-SA 4.0
2022-04-21T09:01:58.057Z
HTTP code 202 does not mean success. It means "The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place."
grim_i_am
<wallet><cardano-node><transaction>
Our valid transaction never posts to the chain. TraceMempoolRemoveTxs in log
# Our valid transaction never posts to the chain. TraceMempoolRemoveTxs in log

(Asked by: username_0 on 2021-11-24)

We are programatically submitting transactions to the blockchain using cardano-wallet. Everything seems to be fine when we do so. cardano-wallet returns a 202 indicating success along with a transaction id and everything else you would expect. However, when we go check the blockchain explorer for the tx it isn't there. As you might expect, the chain never reflects the change (customers don't receive what we send them).
The only thing we see in the logs is that sometime after sending the tx the cardano node will provide the TraceMempoolRemoveTxs error. Here is he full line from the node:
cardano-node-1    | [c7e60f27:cardano.node.Mempool:Info:59] [2021-11-24 20:24:55.43 UTC] fromList [("txs",Array [Object (fromList [("txid",String "txid: TxId {_unTxId = SafeHash \"53625bb985197b9af7e41b12449f70666dcebf8fe9afc65dae29557b31d02d14\"}")])]),("mempoolSize",Object (fromList [("bytes",Number 0.0),("numTxs",Number 0.0)])),("kind",String "TraceMempoolRemoveTxs")]

Now, this event occurs more often than not, but it does not always occur. Sometimes our transactions successfully make it through to the blockchain. We can find no clear pattern on when they do or not.
Does anyone know what is happening here or how we can deal with it?

**Tags:** wallet, cardano-node, transaction
> **Comments:**
> **username_1**: HTTP code 202 does not mean success. It means "The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place."  

---

## 1 answers

### Answer by username_0 on 2021-11-25. Score: 2 | Accepted answer

This occurred because our `time_to_live` in the transaction was too low. The recommended value in iohk documentation is `10` which is woefully inadequate. If this is happening to you bump this up. We set ours to `300` which has been working great.


---

