FM should submit on startup if it hasn't participated in the last round

[boxhock]

No description provided.

[ebarakos]

Any chance we can get this information by querying the blockchain @boxhock ?

[boxhock]

@ebarakos I'll look some more into it, but most likely no - not very easily at least.

[ebarakos]

If we cannot find easily from blockchain, we can persist the 2 values, latestSubmittedRoundID & latestInitiatedRoundID for startup/restarting functionality.

But if we don't, and FM falsely assumes that it can submit(this should not happen frequently), shouldn't this be handled by the smart contract? Like rejecting this submission? What would be the impact?

The exact sentence of the issue headline, seems functional right now, probably this is more related to "FM shouldn't submit on startup if it has participated in the last round"?

[boxhock]

But if we don't, and FM falsely assumes that it can submit(this should not happen frequently), shouldn't this be handled by the smart contract? Like rejecting this submission? What would be the impact?

That's right. The only downside is the node operator wasting some gas, but this shouldn't break anything.

The exact sentence of the issue headline, seems functional right now, probably this is more related to "FM shouldn't submit on startup if it has participated in the last round"?

The main problem right now is that on startup, the node won't send a job run trigger if a new round was started while the EI was offline. We'll probably also need to store the last block number - that way the BM can search the history since that block and see what events have occurred while the EI was offline. Another thing is that the heartbeat should count from the last round - not the startup, so we'll need to know when the last round was. Do you think we should open a separate issue to track that?