[Feature] Define ExecutingMessageValidator

[emhane]

Component

protocol

Describe the feature you would like

Define new trait that has functionality to
(i) parses receipts to extract ExecutingMessages from logs
(ii) validate a list of receipts, using the result from (i) under the hood to use SupervisorApiClient

pub trait ExecutingMessageValidator {
    type SupervisorClient: SupervisorApiClient;

    ...
}

Additional context

API should be flexible to use on single receipts (list of one) and multiple receipts, and flexible to allow parallelising RPC calls to supervisor and extracting messages form logs.

[emhane]

call to SupervisorApi best be it's own trait method, and can take an additional arg timeout: Option<u64> + the trait can have a constant DEFAULT_TIMEOUT. for docs about when trait method returns false, we need to add case when rpc call to supervisor times out.

[emhane]

how about this one @sergerad ?

[sergerad]

Looks good, will start this one after I push something up for #20

[refcell]

FYI @sergerad just merged #128 which contains the supervisor trait in the maili-rpc. I'm not super happy with it living in there so we can move it around if needed :)

[emhane]

@sergerad after looking at home we will use this in op-reth transaction pool, it makes more sense if the trait methods use logs rather than receipts. the reason being that there is no need to construct and entire receipt from execution, when we will only use the logs anyway. that removes the step of extracting logs, the step that remains is extracting executing message events from logs.

[sergerad]

FYI @sergerad just merged #128 which contains the supervisor trait in the maili-rpc. I'm not super happy with it living in there so we can move it around if needed :)

@refcell what is the relationship between pub trait Supervisor from the supervisor module and pub trait SupervisorApi from the api module?

This issue states I should use SupervisorApiClient which is generated from the latter so I'm confused as to the need for the new trait in supervisor module.

TY!

[emhane]

agreed @sergerad let's collapse these two into the one living inside of rpc module...jsonrpsee automatically impls the client version of the trait so the impl in interop crate is redundant. ref https://docs.rs/jsonrpsee/latest/jsonrpsee/async_client/struct.Client.html#method.request

probably makes sense to make the api module in rpc crate into a folder though, and having supervisor api in it's own file since the additional trait methods make it rather much loc

out of scope for this issue though. tldr; use the trait in rpc crate