[bug] Transaction revalidation order

[Arjentix]

By looking at core/srd/block.rs I think there is an issue with our revalidation mechanism. Need to check if I'm right or not.

Steps to test

1. Submit some failing transaction. I.e. spend asset that user don't have or something like that
2. Submit transaction that could make tx 1 be successful if thix tx 2 preceeded it. I.e. mint some asset amount for user

What I expect to happen

I believe that peer other than the one you have submitted these transactions will complain about tx 1 because it should fail but it won't.

So if you submit transaction to peer 1, then it will have tx 1 failed and tx 2 succeed. And all other peers should have some failure in logs, because they will have both transactions successful.

What should happen in valid Iroha 2

Nothing wrong, just every peer agrees about tx 1 being failed

[SamHSmith]

You are right there is a subtle problem here. Assume the sequence Mint, Register, Mint. The first mint fails and gets put in the rejected transactions. But in validation those get validated after, so it actually passes this time. We need to revalidate transactions, in the same order as during creation.

[Arjentix]

But in validation those get validated after, so it actually passes this time. We need to revalidate transactions, in the same order as during creation.

Yeah, that's what I've seen in the code and decided to create this issue. Have you managed to reproduce this bug?

[SamHSmith]

Yes I reproduced it in a test and managed to fix it.