<p>Your answer is found in the <a href="https://github.com/input-output-hk/plutus/blob/master/plutus-contract/src/Plutus/Contract/Request.hs#L372" rel="nofollow noreferrer">Plutus.Contract.Request</a> module of <code>plutus-contract</code>.</p>
<p>It says that: &quot;If the transaction is never added to the ledger then 'awaitTxConfirmed' never returns&quot;.</p>

CC BY-SA 4.0
2021-08-24T13:47:50.367Z
You are right about the comment, but it doesn't explain the reason why `awaitTxConfirmed` would not return
Aoaddeola
CC BY-SA 4.0
2021-08-24T14:16:12.050Z
`awaitTxConfirmed` won't return because if loops indefinitely. If you look at the implementation, it stops looping only when the status of the tx is something other than `Unknown`.
kolam
CC BY-SA 4.0
2021-08-24T14:18:21.573Z
This doesn't explain it, since the `awaitTxConfirmed` isn't recursive
Aoaddeola
CC BY-SA 4.0
2021-08-24T14:30:12.750Z
You see the `go` function inside `awaitTxConfirmed`? It's recursive no?
kolam
CC BY-SA 4.0
2021-08-24T14:45:52.213Z
Ok,  you are right about the recursion... But still, it doesn't tell why it may loop indefinitely :) I'd like to believe that the answer might have more to do with general blockchain documentation and not what can be discerned from code. I might be wrong though
Aoaddeola
CC BY-SA 4.0
2021-08-23T14:45:06.617Z
2021-08-23T22:18:58.000Z
2021-08-23T22:18:58.000Z
kolam
<p>Under what conditions does <code>awaitTxConfirmed</code> not return?</p>
<p>It stopped returning since I updated my <code>cabal.project</code> file to make use of the latest plutus tag <code>plutus-starter-devcontainer/v1.0.7</code>. It worked with <code>plutus-starter-devcontainer/v1.0.6</code>.</p>
<p>The changes that had to be made were as trivial as changing <code>ByteString</code> to <code>BuiltinByteString</code>, <code>mustForgeValue</code> to <code>mustMintValue</code> etc.</p>
<p>The test output looks like:</p>
<pre><code>...
Slot 00003: W1: TxSubmit: b7c6004fe8f4b8cdf94c9b4b3260f4bc60ae4c9fa6ec9d64e4b8f5e4e9c83c5b
Slot 00003: SlotAdd Slot 4
Slot 00004: SlotAdd Slot 5
...
</code></pre>

CC BY-SA 4.0
2021-09-23T04:25:38.717Z
can you post your code where you are actually using `awaitTxConfirmed`?
Matthias Sieber
<plutus>
awaitTxConfirmed not returning
# awaitTxConfirmed not returning

(Asked by: username_0 on 2021-08-21)

Under what conditions does awaitTxConfirmed not return?
It stopped returning since I updated my cabal.project file to make use of the latest plutus tag plutus-starter-devcontainer/v1.0.7. It worked with plutus-starter-devcontainer/v1.0.6.
The changes that had to be made were as trivial as changing ByteString to BuiltinByteString, mustForgeValue to mustMintValue etc.
The test output looks like:
...
Slot 00003: W1: TxSubmit: b7c6004fe8f4b8cdf94c9b4b3260f4bc60ae4c9fa6ec9d64e4b8f5e4e9c83c5b
Slot 00003: SlotAdd Slot 4
Slot 00004: SlotAdd Slot 5
...

**Tags:** plutus
> **Comments:**
> **username_1**: can you post your code where you are actually using `awaitTxConfirmed`?  

---

## 1 answers

### Answer by username_2 on 2021-08-23. Score: 1

Your answer is found in the [Plutus.Contract.Request](https://github.com/input-output-hk/plutus/blob/master/plutus-contract/src/Plutus/Contract/Request.hs#L372) module of `plutus-contract`.

It says that: "If the transaction is never added to the ledger then 'awaitTxConfirmed' never returns".

> **Comments:**
> **username_0**: You are right about the comment, but it doesn't explain the reason why `awaitTxConfirmed` would not return  
> **username_2**: `awaitTxConfirmed` won't return because if loops indefinitely. If you look at the implementation, it stops looping only when the status of the tx is something other than `Unknown`.  
> **username_0**: This doesn't explain it, since the `awaitTxConfirmed` isn't recursive  
> **username_2**: You see the `go` function inside `awaitTxConfirmed`? It's recursive no?  
> **username_0**: Ok,  you are right about the recursion... But still, it doesn't tell why it may loop indefinitely :) I'd like to believe that the answer might have more to do with general blockchain documentation and not what can be discerned from code. I might be wrong though  

---

