services/horizon: Remove Horizon Submission Queue #5039
Merged
Conversation
This file contains 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
aditya1702
changed the title
aditya1702
changed the title
aditya1702
requested review from
sreuland,
tamirms,
2opremio,
Shaptic,
mollykarcher and
urvisavla
Shaptic
reviewed
Sep 11, 2023
sreuland
reviewed
Sep 11, 2023
tamirms
reviewed
Sep 12, 2023
tamirms
reviewed
Sep 12, 2023
tamirms
reviewed
Sep 13, 2023
tamirms
reviewed
Sep 13, 2023
sreuland
reviewed
Sep 13, 2023
|
I think ErrNoAccount can be removed since it seems to not be referenced anywhere |
tamirms
reviewed
Sep 14, 2023
|
I think we can simplify OpenSubmissionList by removing all the error return values from the function signatures. I noticed that none of the functions actually returned any errors except for |
tamirms
reviewed
Sep 15, 2023
tamirms
reviewed
Sep 15, 2023
2opremio
pushed a commit
that referenced
this pull request
Oct 16, 2023
* Remove horizon submission queue - 1 * Update system.go * Update system.go * remove WaitUntilAccountSequence * Update system.go * Remove tests related to WaitUntilAccountSequence - 1 * Update system_test.go * Remove history_transactions_filtered_tmp - 1 * Fix failing tests in system_test.go * Revert "Remove history_transactions_filtered_tmp - 1" This reverts commit d1c6959. * Revert "Fix failing tests in system_test.go" This reverts commit 767a9f9. * Remove sequenceNumber from checkTxAlreadyExists * Undo removing waitUntilAccountSequence * Small change - 1 * Small changes - 2 * fix failing unit tests * Add some comments - 1 * Small changes - 3 * Small changes - 4 * Fix failing tests - 1 * Use defer for sys.finish * Revert "Use defer for sys.finish" This reverts commit b2321be. * Small changes - 5
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.
Closes #4996
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
What
Horizon manages an internal submission queue. This intent of this is to protect/isolate clients from potentially receiving error messages on transaction submission when multiple transactions are submitted very quickly in succession. If transactions (from the same source account) are submitted with sequence numbers out-of-order, then this submission queue will hold those transactions in-memory so that it can re-order them in line with their sequence numbers, allowing all of them to succeed when they are actually submitted to core
This PR:
Why
Recently, core has released a change that prevents the submission of multiple transactions in a ledger for a given account. With this change, the Horizon submission queue is even less likely to provide any benefit to end-users, and if anything cause more confusion. Transactions would be queued up in-memory, only to have only one of them be able to be submitted when they were finally submitted to core.
Known limitations
N/A