Add outcome for previous round missing request ids - #764
yashnevatia wants to merge 17 commits into
Conversation
…smartcontractkit/capabilities into add-outcome-for-prevMissingReqIDs
|
|
||
| for _, requestID := range query.RequestIDs { | ||
| requestIDs := query.RequestIDs | ||
| if rp.config.EnableMissingRequestRecovery { |
There was a problem hiding this comment.
2F+1 nodes must agree on a flag before we can change behavior.
The problem with off-chain config is that nodes can pick it up at different times.
There was a problem hiding this comment.
I think in this case this is onchain config, so it's tied to config digest and guaranteed to be the same across all nodes, no?
There was a problem hiding this comment.
@dhaidashenko @bolekk
The registry syncer is syncing every 12s.
So worst case we will have consensus break for 12s (where 2f nodes just sycned before the update was pushed).
At first glance, i am inclined to think that 12s down time is not good.
However, I am curious if there are other config changes that get pushed via capReg which encounter the same issue ?
There was a problem hiding this comment.
+1 seems like any update to OCR config causes downtime of 12s (assuming that OCR manages to exit instantly - might not be true).
IMO, in this particular case, we can avoid downtime and need to update cap registry (sign 6 proposals - 2 for each env), by including hardcoded EnableMissingRequestRecovery = true in the observation and common value into the outcome. The downside is that we can not disable the feature without a version rollback.
We can address this downside by creating a global boolean flag in the settings and passing it into the observation on every round.
|
3 participants
Ticket: https://smartcontract-it.atlassian.net/browse/PLEX-2894
Depends on: smartcontractkit/chainlink-common#2402