pkg/workflows/dontime: introduce feature flagged fix for sequence number inconsistency - #2361
pkg/workflows/dontime: introduce feature flagged fix for sequence number inconsistency#2361jmank88 wants to merge 3 commits into
Conversation
✅ API Diff Results -
|
…ber inconsistency
01f63a7 to
9cc0558
Compare
| @@ -0,0 +1,24 @@ | |||
| package pb | |||
There was a problem hiding this comment.
Seemed fitting as a method, but could be a helper func instead 🤷
| WorkflowExecutionID: req.WorkflowExecutionID, | ||
| SeqNum: req.SeqNum, | ||
| Timestamp: 0, | ||
| Err: fmt.Errorf("requested seqNum %d for executionID %s is greater than expected based on the max seqNum observed so far %d", |
There was a problem hiding this comment.
I don't think we should error here. What if the plugin didn't process all lower seq numbers in the previous round? I thought we would always add all local requests to observation.
| timestampNodePairs = append(timestampNodePairs, timestampNodePair{Timestamp: observation.Timestamp, NodeID: idx}) | ||
| outcome := prevOutcome | ||
|
|
||
| // Compare with prior outcome to ensure DON time never goes backward. |
There was a problem hiding this comment.
Shouldn't this check happen earlier, before we go into un/sequencedOutcome() ?
|
|
||
| // sequencedOutcome executed the updated outcome logic to produce a sequenced map of [pb.ObservedDonTimes.TimestampsBySequence]. | ||
| func (p *Plugin) sequencedOutcome(ctx context.Context, outctx ocr3types.OutcomeContext, _ types.Query, aos []types.AttributedObservation, donTime int64) (ocr3types.Outcome, error) { | ||
| observationCounts := map[string]int64{} // counts how many nodes reported where a new DON timestamp might be needed |
There was a problem hiding this comment.
nit: comment what is the key in this map
| continue | ||
| } | ||
|
|
||
| if !observation.GetLimitByBatchSizeFlag() { |
There was a problem hiding this comment.
hmm I should've cleaned that up. We can assume this is enabled everywhere by now
| observationCounts[id]++ | ||
| } else if requestSeqNum > currSeqNum { | ||
| // This should never happen since we don't include out of sequence requests in the Observation phase | ||
| p.lggr.Errorf("request seqNum %d for executionID %s is greater than the current seqNum %d", |
There was a problem hiding this comment.
I don't think it's an error any more. Shouldn't we just process the highest number that we can reach consensus on and allow for gaps? cc @cedric-cordenier if I'm missing something here.
https://smartcontract-it.atlassian.net/browse/CRE-5838
Supports: