-
Notifications
You must be signed in to change notification settings - Fork 342
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
Improve behavior on corrupted checkpoint. #4025
Comments
Can I work on this? :) |
Yes, you can. Logging an error and skipping the partition is enough. I don't think self-clean-up is helpful because it's likely that the issue comes from either a bug in the source or a user manually editing a checkpoint. In the first case, the bug will reoccur, and self-cleanup will be less helpful. In the second, I'd rather have users clean up their mess themselves and decide from which point they want to resume indexing the partition. Always restarting from the beginning will yield duplicates. |
Perfect, do you know whereabouts in the codebase the panic(s) occurs? Sounds like it is in |
if you |
Are there any existing tests or test data that would simulate this scenario? |
If a checkpoint contains an invalid position (for instance not u64) for ingest,
we currently panic.
Ideally we should:
This is very defensive and hence low priority
The text was updated successfully, but these errors were encountered: