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

[server] Augment completion report with previous ready to serve state #1288

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ZacAttack
Copy link
Contributor

@ZacAttack ZacAttack commented Nov 7, 2024

[server] Augment completion report with previous ready to serve state

This change persists into the offset record weather or not this partition originally marked itself as ready to serve. This is then used on restart to determine if a node should report completion or not when coming online.

The intention is that when a node is lagged under normal conditions (things like heavy load or some other bad condition), we can still restart the node or do deployments and have the node come up and serve traffic. This is done under the notion that it's generally preferable to be online and serving and stale as opposed to caught up/catching up, but unavailable.

This will not impact buffer replay on a version push because a replay won't pass a ready to serve check.

ALSO

Did some test code cleanup in StoreIngestionTask which had an excessive amount of function overloading. Switched it over to use a config object instead and migrated the code over.

Resolves #XXX

How was this PR tested?

Does this PR introduce any user-facing changes?

  • No. You can skip the rest of this section.
  • Yes. Make sure to explain your proposed changes and call out the behavior change.

This change persists into the offset record weather or not this partition originally marked itself as ready to serve.  This is then used on restart to determine if a node should report completion or not when coming online.

The intention is that when a node is lagged under normal conditions (things like heavy load or some other bad condition), we can still restart the node or do deployments and have the node come up and serve traffic.  This is done under the notion that it's generally preferable to be online and serving and stale as opposed to caught up/catching up, but unavailable.

This will not impact buffer replay on a version push because a replay won't pass a ready to serve check.
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.

1 participant