Tracking the lifecycle of a transaction is super important for any application to ensure that any state changes were committed to the blockchain. The dfuse Platform is the only one to provide such a powerful lifecycle, including the ability to track the complete lifecycle of deferred transactions. A feature unique to dfuse.
Today the video is about the lifecycle endpoint that we're offering. This is an amazing thing, and it's also a dfuse differentiator. It is an endpoint that will give you the full lifecycle story of your transaction.
What does that mean? So we talked in a previous video about the fact that when you send a transaction, it can be included in a block, go through the irreversibility, or it can never be included in a block somehow. There's some situations which make it never settle. Well maybe you want to know about these things. So when you query the `transaction_lifecycle` endpoint of the dfuse Platform, we will tell you if the transaction is inside a block. Was it executed? Did it fail?
There are two modes of failure, soft fail and hard fail. We will give you the trace for the failure. We will give you all the stack trace. We will also give you the console output. So as a contract developer, if you put print statements in there, dfuse is the only platform that will give you the output from the console. So you can do debugging in prod. ...don't do that. Test on your testnet before… But the other awesome thing that it does is it tracks the whole lifecycle of deferred transactions. And that is unique. So it means if your transaction made it to the blockchain as a deferred, maybe it's deferred for 5 days… so the lifecycle would indicate, and show you the transaction that is not yet executed. Is it in a block? It's in a block in a way. It's waiting. It's in the blockchain memory and it's waiting for execution in the future. But many things can happen to that transaction. It can be cancelled, it can be executed, and it can expire. If they're eventually executed, then you'll want to know.
If you query the lifecycle endpoint we'll say "This was the transaction, deferred at that point in that block. It is now executed in that block." But that might change, remember? Because of microforks. So if you query many times you will know the state. In which block it was executed, you can know the head of the block, or it will indicate if this one is now irreversible. If the execution is irreversible and if the creation is irreversible, because there are two steps now.
There's also something else that can happen. It can be cancelled. If you call the `canceldelay` action on the system contract, you can also cancel the transaction that was in-flight. Meaning it was in the memory of the blockchain waiting for it's delay to expire and then be executed. So if you do that, you have yet another lifecycle event. You have the creation and then the cancellation. If you get that, you'll never get execution because it was cancelled. But the cancellation can also be part of a fork, so you want to know that.
If you query the lifecycle and you have a cancelled transaction that was deferred, you'll get the deferred, where it was deferred, whether it is irreversible or not, and then the cancellation. Whether this one is irreversible or not. Or it's going to be switched for an execution. And that can happen.
So by querying the lifecycle endpoint, you'll have all the state machine of the deferred transaction, of the lifecycle also of a normal transaction that was just pushed and executed, and whether it's irreversible or not. And the last case is expiration. If your transaction was in the memory of the blockchain, but it was systematically - even after the delay was passed - let's say 5 seconds... after 5 seconds no Block Producer ran it for (I think there's a minimum there) 10 minutes. If it expires, then it's going to be purged out of the blockchain. And you want to know that. If your transaction was just expired, no one accepted to run it. That will be most of the time because of either failed execution or subjective rejection by the Block Producers of that transaction.
So I think that covers it. The `transaction_lifecycle` endpoint, the unique features of the dfuse Platform. The dfuse Platform is the only system around that allows you to track deferred transactions. If you go to eosq.app, you'll notice all that rich information is displayed. If you select a transaction that was deferred, you can navigate to the previous transaction who created it, who cancelled it, who executed it, and which blocks all these things happened. eosq is actually a great demo website of the power of the dfuse Platform. Everything under eosq.app, which is our block explorer, is powered by dfuse. eosq is just a front end. So take a look and if you have any questions join our Telegram channel for dfuse API.