Execution report

[Eitu33]

Context

This idea comes from a discussion with @damip following the work currently being done by @bilboquet in #3562.

Currently, if a user sends an operation in the network he has no information on the status of this operation. He knows only:

• if it is in the pool
• in which block(s) the operation was included
• if the block in which is was included is final (this is not even associated to the list of blocks that included it)

The PR about showing the execution status will add:

• if the operation itself is final (execution final)
• if the operation execution succeeded or failed

But the following information is still unavailable to the user:

• asynchronous messages execution status
• if an operation treatment failed before being executed (not enough gas, already executed etc.)
• if it was already executed before, the information retrieved corresponds to the previously executed operation, and the user will have no way to tell if it was his operation or another

Solution

The goal is to have some kind of execution report of what happened in which order for each slot. The data structure could be something like:

type ReportHistory = Map<Slot, Map<Index, Report>>;

struct Report {
  source: OpOrMessage,
  input: InputInfo,
  result: Result<()>,
}

Now the question is what system would we rather have to handle the reports? Do we want to save them in the node and make them available through the API? Do we want emit the reports as they come and allow users to listen to them? Are other systems better suited for this purpose?

[AurelienFT]

asynchronous messages execution status

In case of infinite loop what we will have ?

failed before being executed (not enough gas)

No enough gas happens while executing not before. I assume you wanted to say "failed for reason non-user (sc developer) designed" ?

if it was already executed before, the information retrieved corresponds to the previously executed operation, and the user will have no way to tell if it was his operation or another

I don't understand this point

Do we want to save them in the node and make them available through the API?

For me this point out to something more bigger that we need to think of with the new API. What should be served by the node ? And what should be interpreted for the data we serve to create something more high level (like the block explorer that could serve an high level API). I don't think we want to include a lot of complex things directly in the node and in the module themself. @aoudiamoncef it would be nice to have your input on that

[Eitu33]

asynchronous messages execution status
In case of infinite loop what we will have ?

Out of execution gas.

failed before being executed (not enough gas)
No enough gas happens while executing not before. I assume you wanted to say "failed for reason non-user (sc developer) designed" ?

I meant block gas.

if it was already executed before, the information retrieved corresponds to the previously executed operation, and the user will have no way to tell if it was his operation or another
I don't understand this point

If an operation as been already executed and a user tries to emit the same operation, it fails. But when the same user will try to retrieve information concerning that operation he will receive the data of the first one.

Do we want to save them in the node and make them available through the API?
For me this point out to something more bigger that we need to think of with the new API.

I agree.

[AurelienFT]

Out of execution gas.

No but like async message that send, async message that send async message etc... in a network with 0 fees

I meant block gas.

So it's not a fail it will just be included in an other block.

[Eitu33]

No but like async message that send, async message that send async message etc... in a network with 0 fees

Well then you would just have the report on every time the new message will be executed, I don't see the issue here.

So it's not a fail it will just be included in an other block.

Not necessarily you can put too much operations in a block, yes it can be included in another block but its stil an operation that existed and wasn't executed.

[AurelienFT]

Well then you would just have the report on every time the new message will be executed, I don't see the issue here.

Ah ok I misunderstood I thought that the async message report will be included in the operation one and so it could lead to an inifinite list.

its stil an operation that existed and wasn't executed.

Ok but it's not a fail it's just an operation that wait for the network to be less used to pass.

[damip]

In any case, all kinds of polling will have very limited usefulness because blocks/ops are forgotten. Massa is fundamentally a streaming-oriented system. The best course would be that Execution reports every action it does and its outcome through an outbound GRPC stream. The client can then listen to all the events of interest, store them, notify the user etc...

Example of stream (I wrote the entries in plaintext but it should be proto objects):

• Executing slot [slot] at [timestamp]
• Executing async messages at slot [slot]
• Executing async message [id]:
  • outcome: Result<...>
• Executing async message [id]:
  • outcome: Result<...>
• Executing block [block ID] at slot [slot]
• Executing operation [id]:
  • outcome: Result<...>
• Executing operation [id]:
  • outcome: Result<...>
• Finished slot execution [slot]
• Executing slot [slot] at [timestamp]
• Executing async messages at slot [slot]
• Executing async message [id]:
  • outcome: Result<...>
• Executing async message [id]:
  • outcome: Result<...>
• Executing block [block ID] at slot [slot]
• Executing operation [id]:
  • outcome: Result<...>
• Executing operation [id]:
  • outcome: Result<...>
• Finished slot execution [slot]
• Finalized slot [slot]
• Blockclique changed: lost blocks [blockId1, blockId2], added blocks [blockId3, blockID4, ..], resuming execution from slot [slot]

[aoudiamoncef]

IMHO, the polling model showed it's limits in the Massa API V1. If a resource(Block/Operation...etc) is designed to be forgot, we shouldn't confuse the client who thinks that the resource is idempotent. We should rely on external solutions to keep track and query the node produced data. In case of persisted resources, it's fine to have a simple RPC call.

We could be verbose in term of generated events as it's designed in fire and forget model. But sometimes, we have to adjust some responses depending on the content of requests(at runtime) so every client will have a custom output.

We should avoid introducing additional complexity to our node.

[bilboquet]

I feel like it's related to what you say here: #3591