Skip to content

fix(prot): order synthetic transactions by sequence number [AC-1703]

Ethan Reesor requested to merge AC-1703 into develop

Updates AC-1703. Synthetic transactions are initially submitted in order, but they go onto a pending list until the receiver is able to build a complete proof. Once that happens, the receiver internally resubmits them. But because of how this works, they are resubmitted in an arbitrary order (probably ordered by the transaction hash), which can lead to a wall of "out of order" messages. So this MR reorders the synthetic transactions by sequence number to prevent that.

The executor can handle out of order synthetic transactions, but A) I don't like seeing all those log messages, B) it makes things unnecessarily complex give that it is easy to fix, and C) I'm hoping it will fix AC-1703.

Review Checklist

If any item is not complete, the merge request is not ready to be reviewed and must be marked Draft:.

  • The merge request title is in the format <change type>(<change scope>): <short description> [<task id>]
    • For example, feat(cli): add QR code generation [AC-123]
    • For details, see CONTRIBUTING.md
  • The description includes Closes <jira task ID> (or rarely Updates <jira task ID>)
  • The change is fully validated by tests that are run during CI
    • In most cases this means a test in "validate.sh"
    • In some cases, a Go test may be acceptable
    • Validation is not applicable to things like documentation updates
    • Purely UI/UX changes can be manually validated, such as changes to human-readable output
    • For all other changes, automated validation tests are an absolute requirement unless a maintainer specifically explains why they are not in a comment on this merge request
  • The change is marked with one of the validation labels

Merge Checklist

  • CI is passing
  • Merge conflicts are resolved
  • All discussions are resolved

Related to AC-1703

Edited by Ethan Reesor

Merge request reports