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

Fail loadgen when pending accounts are found in available accounts list #4372

Merged
merged 2 commits into from
Jul 1, 2024

Conversation

bboston7
Copy link
Contributor

Description

Although mAccountsAvailable shouldn't contain pending accounts, it is possible when the network is overloaded. Consider the following scenario:

  1. A node generates a transaction t using account a and broadcasts it on. In doing so, loadgen marks a as in use, removing it from `mAccountsAvailable.
  2. For whatever reason, t never makes it out of the queue and the node bans it.
  3. After some period of time, the node unbans t because bans only last for so many ledgers.
  4. Loadgen marks a available, moving it back into mAccountsAvailable.
  5. The node hears about t again on the network and (as it is no longer banned) adds it back to the queue
  6. getNextAvailableAccount draws a from mAccountsAvailable. However, a is no longer available as t is in the transaction queue!

In this scenario, returning a results in an assertion failure later. This change instead detects this and marks the loadgen run as failed.

Checklist

  • Reviewed the contributing document
  • Rebased on top of master (no merge commits)
  • Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
  • Compiles
  • Ran all tests
  • If change impacts performance, include supporting evidence per the performance document

Although `mAccountsAvailable` shouldn't contain pending accounts, it is
possible when the network is overloaded. Consider the following
scenario:
1. A node generates a transaction `t` using account `a` and
   broadcasts it on. In doing so, loadgen marks `a` as in use,
   removing it from `mAccountsAvailable.
2. For whatever reason, `t` never makes it out of the queue and the
   node bans it.
3. After some period of time, the node unbans `t` because bans only
   last for so many ledgers.
4. Loadgen marks `a` available, moving it back into
   `mAccountsAvailable`.
5. The node hears about `t` again on the network and (as it is no
   longer banned) adds it back to the queue
6. getNextAvailableAccount draws `a` from `mAccountsAvailable`.
   However, `a` is no longer available as `t` is in the transaction
   queue!

In this scenario, returning `a` results in an assertion failure
later. This change instead detects this and marks the loadgen run as failed.
src/simulation/LoadGenerator.cpp Outdated Show resolved Hide resolved
src/simulation/LoadGenerator.cpp Outdated Show resolved Hide resolved
src/simulation/LoadGenerator.cpp Outdated Show resolved Hide resolved
Copy link
Contributor

@marta-lokhova marta-lokhova left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@marta-lokhova marta-lokhova added this pull request to the merge queue Jul 1, 2024
Merged via the queue into stellar:master with commit ca55fa3 Jul 1, 2024
14 checks passed
@bboston7 bboston7 deleted the get-next-account-fix branch July 2, 2024 19:44
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.

2 participants