Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

services/horizon/internal/txsub: Check transaction submission results using repeatable read transaction #2805

Merged
merged 5 commits into from
Jul 14, 2020

Conversation

tamirms
Copy link
Contributor

@tamirms tamirms commented Jul 10, 2020

PR Checklist

PR Structure

  • This PR has reasonably narrow scope (if not, break it down into smaller PRs).
  • This PR avoids mixing refactoring changes with feature changes (split into two PRs
    otherwise).
  • This PR's title starts with name of package that is most changed in the PR, ex.
    services/friendbot, or all or doc if the changes are broad or impact many
    packages.

Thoroughness

  • This PR adds tests for the most critical parts of the new functionality or fixes.
  • I've updated any docs (developer docs, .md
    files, etc... affected by this change). Take a look in the docs folder for a given service,
    like this one.

Release planning

  • I've updated the relevant CHANGELOG (here for Horizon) if
    needed with deprecations, added features, breaking changes, and DB schema changes.
  • I've decided if this PR requires a new major/minor version according to
    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

Check transaction submission results using repeatable read transaction.
Fixes #2628

Why

We make two DB queries: first checking if tx result exists in a DB (ResultByHash), second getting the current sequence number of a source account (GetSequenceNumbers):

Queries are not sent in a transaction (REPEATABLE READ) so it's possible that ResultByHash and GetSequenceNumbers are getting data for different ledgers: one without a tx ingested, second with tx ingested which can result in bad_seq errors.

Because we are using Horizon DB only I think we should remove ResultProvider and SequenceProvider interfaces and use history.Q directly to send queries.

Known limitations

Previously, when we wrapped horizon endpoints in repeatable read transactions this resulted in some performance degradation. We will need to test that production load does not overwhelm the horizon db.

@cla-bot cla-bot bot added the cla: yes label Jul 10, 2020
@tamirms tamirms force-pushed the txsub-repeatable-read branch 4 times, most recently from e0ad5b6 to 16ad6b6 Compare July 10, 2020 17:55
@tamirms tamirms force-pushed the txsub-repeatable-read branch from 16ad6b6 to 06a6c60 Compare July 10, 2020 18:01
@tamirms tamirms requested a review from a team July 10, 2020 18:06
services/horizon/internal/init.go Show resolved Hide resolved
return tx, err
}

func checkTxAlreadyExists(db HorizonDB, hash, sourceAddress string) (history.Transaction, uint64, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a short comment explaining why this has to be done in a repeatable read tx. And let's error.Wrap all errors in this function.

services/horizon/internal/txsub/system.go Outdated Show resolved Hide resolved
@tamirms tamirms force-pushed the txsub-repeatable-read branch from 2720512 to d40502c Compare July 14, 2020 15:18
@tamirms tamirms merged commit 59324f1 into stellar:release-horizon-v1.6.0 Jul 14, 2020
@tamirms tamirms deleted the txsub-repeatable-read branch July 14, 2020 15:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Horizon returned bad sequence error although the transaction was added to ledger
2 participants