Skip to content

persist: add flag for lower bound validations on read #32802

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

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

Conversation

ptravers
Copy link
Contributor

Motivation

9399

Tips for reviewer

adds a feature flag to enable turning off validation of batch vs part lower bounds on read from persist.

Checklist

  • This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
  • This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
  • If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
  • If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
  • If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

@ptravers ptravers changed the title persist: add flag for enabling and disabling batch lower bound validations on read persist: add flag for lower bound validations on read Jun 23, 2025
let data_stream = data_stream.flat_map(|part| {
let part = part.parse();
let data_stream = data_stream.flat_map(move |part| {
let part = part.parse(persist_cfg.clone());
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is all pretty gross. I wonder if it would make more sense to have the public parse just take a bool for validation enabled?

Copy link
Contributor

@bkirwi bkirwi Jun 23, 2025

Choose a reason for hiding this comment

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

I think the least gross version would be to store the FetchConfig as a field in the BatchFetcherConfig, then add it as a field on FetchedBlob. That should prevent any changes outside the persist-client codebase, and it's lightly more consistent...

@ptravers ptravers requested a review from bkirwi June 23, 2025 18:25
@ptravers ptravers marked this pull request as ready for review June 23, 2025 19:03
@ptravers ptravers requested review from aljoscha and a team as code owners June 23, 2025 19:03
@ptravers ptravers requested a review from def- June 23, 2025 19:03
Copy link
Contributor

@def- def- left a comment

Choose a reason for hiding this comment

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

Test changes lgtm

@@ -369,6 +370,7 @@ pub async fn blob_batch_part(
}

async fn consolidated_size(args: &StateArgs) -> Result<(), anyhow::Error> {
let cfg = PersistConfig::new_default_configs(&READ_ALL_BUILD_INFO, SYSTEM_TIME.clone());
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd use state_versions.cfg instead here if we can, just to avoid having to potentially-divergent configs floating around...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done.

Self {
validate_lower_bounds_on_read: cfg.fetch_validate_lower_bounds_on_read,
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

If you don't feel strongly, can we store the FetchConfig as a field on CompactConfig, like we do for the BatchBuilderConfig? A bit closer to the existing code / saves some duplication.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done.

let data_stream = data_stream.flat_map(|part| {
let part = part.parse();
let data_stream = data_stream.flat_map(move |part| {
let part = part.parse(persist_cfg.clone());
Copy link
Contributor

@bkirwi bkirwi Jun 23, 2025

Choose a reason for hiding this comment

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

I think the least gross version would be to store the FetchConfig as a field in the BatchFetcherConfig, then add it as a field on FetchedBlob. That should prevent any changes outside the persist-client codebase, and it's lightly more consistent...

@ptravers ptravers requested a review from bkirwi June 24, 2025 20:04
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.

3 participants