Description

Out actions issues

All of the issues described are the result of the following MR #98

Out actions parsing

Parsing code:11e5de0#diff-3926fb733dc0373eb9cfe3b211cace42fa90fbc8b3a58685a5f53f426f39770eR377-R381) totally relies on the fact that
all of the actions in the OutList will be valid.
In reality OutList contains not only successfully executed actions, but
all of the constructed actions instead, including malformed ones.

As a result, on malformed action, following code will throw unhandled exception,
interrupting the whole emulation chain.

I'll provide the fix for this part of the issue.

Mode to action mapping

11e5de0#diff-1793e37fa2cd59365dcf2bff31f2190c2f1bd91a1fdb9d715e7895829009f7dfR537

This seemingly straightforward piece of code maps sendMsg action to it mode.
However, this will only work when there is no skipped sendMsg actions.
And skipping sends is pretty normal, since there is a special flag +2 for that.

As a result, if two messages are sent in same modes, but
first one was skipped, the transaction will get the mode from the skipped one.

Potential to fix

Of course, we can compare message fileds and such, to determine
if the message in actionList matches the one at the outMsgs index,
and sometimes this will work.
However, in corner case of two same messages and different modes,
i don't see any reliable solution yet, since actions are not(to my knowledge) marked as skipped in any way by the TVM.

General sense behind the feature

Having access to the action list of a transaction maybe come handy sometimes.
But attaching the mode to the message object, and more so attaching mode
to the resulting transaction makes no sense to me at all.
11e5de0#diff-1793e37fa2cd59365dcf2bff31f2190c2f1bd91a1fdb9d715e7895829009f7dfR508

Since no message or transaction really has mode, this feels more misleading that any good.
I would even think on rolling back that part.

Steps to Reproduce

Cases

Malformed message

Most common case of malformed sendMsg action
is the addr_none in the destination address.

Skipped action

Most simple case would be to send two messages

1. Requesting to send more than there is on the balance
2. Normal message in mode 64 for example

And then check the resulting modes.
I'll provide tests in the PR.

Environment

No response

Logs or Screenshots

No response