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

KCL 1.X - Guardrails to avoid checkpoint corruption during resharding #779

Merged
merged 2 commits into from
Jan 26, 2021

Conversation

ashwing
Copy link
Contributor

@ashwing ashwing commented Jan 26, 2021

  1. Update the checkpoint with non SHARD_END sequence number only if t…he DDB sequence number is not SHARD_END.
  2. Verify the shard end checkpointing by directly looking up the ddb lease entry

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

…he DDB sequence number is not SHARD_END.

2. Verify the shard end checkpointing by directly looking up the ddb lease entry
@ashwing ashwing linked an issue Jan 26, 2021 that may be closed by this pull request
request.setExpected(serializer.getDynamoLeaseCounterExpectation(lease));
Map<String, ExpectedAttributeValue> expectations = serializer.getDynamoLeaseCounterExpectation(lease);
expectations.putAll(serializer.getDynamoLeaseCheckpointExpectation(lease));
request.setExpected(expectations);
Copy link
Contributor

@joshua-kim joshua-kim Jan 26, 2021

Choose a reason for hiding this comment

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

I believe this is also used for leaseRenewal/leaseStealing codepath, where we're heartbeating the lease counter/owner. We don't necessarily expect SHARD_END in this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't see this being used anywhere other than checkpoint code path. And we don't expect SHARD_END here. We expect it not to present when we write a non SHARD_END checkpoint.

* @param lease
* @return the attribute value map asserting that the checkpoint state is as expected.
*/
default Map<String, ExpectedAttributeValue> getDynamoLeaseCheckpointExpectation(T lease) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe good to rename this to something like getDynamoLeaseShardEndCheckpointExpectation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just want to keep this generic, so that we can add any future state expectations. Also this would set expectation based on checkpoint in the lease.

Copy link
Contributor

@joshua-kim joshua-kim left a comment

Choose a reason for hiding this comment

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

LGTM

@ashwing ashwing merged commit b04e93e into v1.x Jan 26, 2021
@ashwing ashwing deleted the shard_end_corruption_issues_1 branch January 26, 2021 23:34
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.

KCL version 1.14.0 Bugs
3 participants