Conversation
17255ea to
096f21a
Compare
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
096f21a to
1f87289
Compare
peterbroadhurst
left a comment
peterbroadhurst
left a comment
There was a problem hiding this comment.
One minor request for a comment, with approval
| func (bl *blockListener) seedMonitoredHead() *ethrpc.BlockInfoJSONRPC { | ||
| bl.canonicalChainLock.RLock() | ||
| highestBlockSet := bl.highestBlockSet | ||
| highestBlock := bl.highestBlock |
There was a problem hiding this comment.
So the key change is this is still read inside the lock, but we use it outside the lock below as a threshold to preemptively catch up to blocking this function until all those blocks are fetched (or one isn't available)
| bl.reconcileCanonicalChain(bi) | ||
| } | ||
|
|
||
| bi := fetchBlock(highestBlock) |
There was a problem hiding this comment.
Why is this outside of the loop as a separate item, vs just <=?
There was a problem hiding this comment.
Seems like it's because we don't call reconcileCanonicalChain - but why isn't that necessary just for the last block if it is for all the others?
There was a problem hiding this comment.
Ok - found this in the comments on the issue. Maybe add as a comment above this line.
the last block is still returned for the listen loop's first iteration to reconcile as before, preserving existing notification timing
There was a problem hiding this comment.
Will add the comment.
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
…er-firefly/evmconnect into client-side-filtering-startup-fetch Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
…er-firefly/evmconnect into client-side-filtering-startup-fetch
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
| startDone: make(chan struct{}), | ||
| initialBlockHeightObtained: make(chan struct{}), | ||
| newHeadsTap: make(chan struct{}), | ||
| newHeadsTap: make(chan struct{}, 1), // buffer 1 so a tap is not dropped if the listen loop is not currently waiting |
There was a problem hiding this comment.
fix intermittent test failure https://github.com/hyperledger-firefly/evmconnect/actions/runs/34322838066/job/102373183168
2 participants
Summary
NOTE: this gap affects the full tracking mode + client filtering most due to the usage of
steadyStateScanCeilingwhen deciding the highest block to fetch to.seedMonitoredHeadpreviously fetched only a single anchor block (highestBlock-checkpointBlockGap+1), leaving the rest of the monitored window to fill in one block at a time as the live block filter delivered new blocks - paced by real chain block production rather than polling interval.steadyStateScanCeilingin full chain-tracking mode, delaying client-sidegetLogspolling from reaching the chain head. It also affectedReconcileConfirmationsForTransaction(validateChainCaughtUp), which returnsFF23062for any transaction in that gap until the window catches up - this applies to full mode regardless offilterPollingMode(server or client).seedMonitoredHeadnow fetches and reconciles the whole window up front. All but the last block are reconciled silently (no consumer notification, since they're historical, not new); the last block is still returned for the listen loop's first iteration to reconcile as before, preserving existing notification timing. On any fetch failure it falls back to the original one-block-at-a-time behavior.Test plan
go build ./...go vet ./...go test ./...TestBlockListenerSeedMonitoredHead_BlockFound/_ReconcileAndDispatchfor the new return-value contract (top of window, not the anchor), with new coverage asserting the backfilled blocks land inSnapshotMonitoredHeadChain()