In rare cases, proposal duty messages are received before the duty starts.
These messages are rejected with no duty for this epoch since the proposal duties store is not yet populated at that time.
2nd aspect related to message recieval/processing is (I think):
even if we have a duty running, QBFT messages can be received but not processed because there isn't a running QBFT Instance yet - in that case I think the message processing will stop with the following error: future msg from height, could not process - https://github.com/ssvlabs/ssv/issues/1825 goes into more details
3rd aspect
it seems if an operator's Ethereum node(s) is temporarily following a different "tip-fork" (compared to what other operators' Ethereum node(s) follow in his cluster) he can't really participate in duty execution(s) (and also is probably trying to kick off and propose duties other operators don't recognize - due to duties differing for different Ethereum "tip-forks"). This is because share-signing is tightly coupled to duty-execution - while it seems these 2 activities can be done somewhat independently from each other, to resolve this a significant change to the overall SSV node architecture would be required ?
In rare cases, proposal duty messages are received before the duty starts. These messages are rejected with
no duty for this epoch
since the proposal duties store is not yet populated at that time.