Repository navigation
sort queued items before dispatching in light mode for non-zero confirmation - #186
Merged
Merged
Conversation
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
| // processBlock's notifications in full chain tracking mode - we must sort by block order | ||
| // before dispatching, or events can be delivered out of order (and then dropped downstream | ||
| // as apparent re-detections once the checkpoint moves past them). | ||
| sort.Sort(items) |
Contributor
There was a problem hiding this comment.
Cool the ordering is here:
transaction-manager/internal/confirmations/confirmations.go
Lines 213 to 225 in 5915cbc
peterbroadhurst
approved these changes
Sep 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
In light chain tracking mode with
confirmationsRequired > 0, events dispatched from the confirmation manager weren't guaranteed to be in block order. This could occasionally lead to a later-arriving event being treated by the event stream as a re-detection of an earlier one, so it wasn't forwarded. This path isn't used whenconfirmationsRequired = 0or during catch-up.Root cause
checkAndDispatchConfirmationsUsingBlockHeightbuilds its list of newly-confirmable items frombcm.pending, a Go map. Map iteration order isn't guaranteed, so when a head block update confirmed several pending events at once, they were dispatched in map order rather than block order.Full chain tracking mode already handles this correctly in
processBlockviasort.Sort(notifications)before dispatch. Light mode was missing the equivalent sort.Fix
Sort pending items by block number, transaction index, and log index (using the existing
pendingItemssort type) before dispatching incheckAndDispatchConfirmationsUsingBlockHeight, bringing it in line with full mode.Testing
TestBlockConfirmationManagerHeadBlockNumberDispatchesInBlockOrder, which confirms a batch of light-mode events together via one head block update and asserts dispatch order. It reproduced the ordering issue consistently before the fix and passes consistently after.go build ./...,go vet ./..., and theinternal/confirmationssuite all pass.go test ./...run has two unrelated pre-existing failures inpersistence/dbmigrationandpersistence/postgres(agolang-migratepanic in this environment), present onmainbefore this change too.🤖 Generated with Claude Code