4

Applied is self explanatory but the others really arent. The source code gives a bit of clues though; as file apply_results.mli says

[Skipped] ones should always be at the tail, and after a single [Failed]

So in which cases would failed be used over backtracked, and vice-versa? And will we always have guaranteed atomicity on the entire group of transactions in an operation?

| improve this question | |
  • Just a guess, but say we have transactions A that generated internal transactions B C and D. If C, fails, then C is Failed, A and B are Backtracked and D is Skipped. – arvidj Feb 23 at 9:24
5

The idea is pretty simple:

  • failed - operations which failed with some particular error (not enough balance, gas limit, etc);
  • backtracked - operations which were successful but reverted due to one of the following operations in the same operation group was failed;
  • skipped - all the operations after the failed one.

However, after Babylon update some errors cause the operation to be marked as backtracked, but not failed. For example, when sender can't pay allocation fee.

So, it looks like this:

Operation group:
  backtracked
  backtracked
  backtracked
  failed (or backtracked)    <-- here is the actual error
  skipped
  skipped
  skipped

And yes, all operations in the same operation group are atomic.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.