Skip to content

[config] Move bloom_false_positive_rate from dev_tweaks to storage - #6544

Open
mihaibudiu wants to merge 1 commit into
feldera:mainfrom
mihaibudiu:issue5424
Open

[config] Move bloom_false_positive_rate from dev_tweaks to storage#6544
mihaibudiu wants to merge 1 commit into
feldera:mainfrom
mihaibudiu:issue5424

Conversation

@mihaibudiu

Copy link
Copy Markdown
Contributor

Fixes #5424

The old dev_tweaks option is still present, but it is marked as deprecated. If the storage option is present it is used first, and the dev_tweaks option is used otherwise.

The option is also documented publicly.

@mihaibudiu
mihaibudiu requested a review from blp June 25, 2026 23:37
@lalithsuresh

Copy link
Copy Markdown
Contributor

Do we know if this option is safe to modify on a pipeline without resetting state?

@mihaibudiu

Copy link
Copy Markdown
Contributor Author

I don't know if it's safe, but the PR doesn't change this property.

@mythical-fred mythical-fred left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

LGTM. Clean migration:

  • New storage.bloom_false_positive_rate field with full doc and the f64 round-trip regression test that mirrors the pattern in dev_tweaks. Good defensive testing — that serde(deserialize_with = "crate::serde_via_value::deserialize") trick is exactly the bit that has bitten f64 fields through #[serde(flatten)] before.
  • Runtime::bloom_false_positive_rate() prefers storage, falls back to dev_tweaks. The dev_tweaks fallback still returns 0.0001 when unset, so behaviour for pipelines on neither field is unchanged.
  • dev_tweaks field kept and documented as deprecated — that's the right deprecation shape (don't break configs in-flight).
  • impl Eq for StorageOptions is fine: serde_json cannot produce NaN for f64, and nothing in the codebase writes NaN explicitly here.

Docs (memory.md) and openapi.json regenerated. No issues.

@blp

blp commented Jun 26, 2026

Copy link
Copy Markdown
Member

Do we know if this option is safe to modify on a pipeline without resetting state?

Yes.

@blp blp closed this Jun 26, 2026
@blp blp reopened this Jun 26, 2026
@mihaibudiu
mihaibudiu added this pull request to the merge queue Jun 26, 2026
@ryzhyk

ryzhyk commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

@mihaibudiu , have you tested that this doesn't break existing pipelines?

@mihaibudiu

Copy link
Copy Markdown
Contributor Author

Isn't this what CI is supposed to test?

@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 26, 2026
@mihaibudiu
mihaibudiu added this pull request to the merge queue Jun 26, 2026
@gz
gz removed this pull request from the merge queue due to a manual request Jun 26, 2026
@gz

gz commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Isn't this what CI is supposed to test?

these config changes have historically been messy and we dont test it enough in CI.
Lets make sure we at least test it manually and go through a pipeline upgrade using old version -> new version of pipeline manager, pipeline version upgrade etc. before we move things around.

@mihaibudiu

Copy link
Copy Markdown
Contributor Author

Is there a test which exercises the upgrade I should be running?

Signed-off-by: Mihai Budiu <mbudiu@feldera.com>

@mythical-fred mythical-fred left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Rebased over ~436 commits of main; PR content (the six touched files) is identical to the tip I approved on 2026-06-26. Re-approving so the button lights up on the current base.

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.

[doc] Bloom filter memory usage is not documented

6 participants