compute: remove the correction v1 buffer - #38484
Open
antiguru wants to merge 2 commits into
Open
Conversation
The `enable_compute_correction_v2` flag has served `true` in production for every build at or beyond 26.7.0-rc.1, so the v1 correction buffer is dead code in every deployment we support. This change deletes it along with the flag that selected between the two implementations. `CorrectionV2` becomes the only `Correction`, and its file moves to `sink/correction.rs`. The logging and metrics helpers that both implementations shared move to `sink/correction/logging.rs`, which keeps the buffer file from growing further. `Correction::new` now reads the chain proportionality and chunk size from the `ConfigSet`, matching the constructor the sink previously called on the enum wrapper; `Correction::with_params` takes the two values directly for tests and benchmarks. Removing v1 also removes its only consumer of `ConsolidatingVec`, so that type and the `consolidating_vec_growth_dampener` dyncfg that tuned it are gone as well. Both flag keys move to the LaunchDarkly consistency check's stale list, because the last published release still synchronizes them. The `equivalence_with_v1` unit test compared the two implementations step by step. It is replaced by `equivalence_with_reference`, which runs the same upsert-and-feedback workload against a naive in-test buffer that keeps every update in a flat vector, plus an assertion that each step emits something so the comparison cannot pass vacuously. The correction benchmark loses its version-dispatch wrapper and now measures the single implementation. The dyncfg keys `compute_correction_v2_chain_proportionality` and `compute_correction_v2_chunk_size` keep their names. Renaming them would drop the production overrides currently set against those keys. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rustdoc rejects an intra-doc link from a public module's documentation to a crate-private item. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
enable_compute_correction_v2flag has servedtruein production for every build at or beyond 26.7.0-rc.1, so the v1 correction buffer is dead code in every deployment we support. This removes it along with the flag that selected between the two implementations.CorrectionV2becomes the onlyCorrection, and its file moves tosink/correction.rs. The logging and metrics helpers that both implementations shared move tosink/correction/logging.rs, which keeps the buffer file from growing further.Correction::newnow reads the chain proportionality and chunk size from theConfigSet, matching the constructor the sink previously called on the enum wrapper;Correction::with_paramstakes the two values directly for tests and benchmarks.Removing v1 also removes its only consumer of
ConsolidatingVec, so that type and theconsolidating_vec_growth_dampenerdyncfg that tuned it are gone as well. Both flag keys move to the LaunchDarkly consistency check's stale list, because the last published release still synchronizes them. The flags themselves still need archiving in LaunchDarkly.The
equivalence_with_v1unit test compared the two implementations step by step. It is replaced byequivalence_with_reference, which runs the same upsert-and-feedback workload against a naive in-test buffer that keeps every update in a flat vector, plus an assertion that each step emits something so the comparison cannot pass vacuously. The correction benchmark loses its version-dispatch wrapper and now measures the single implementation.The dyncfg keys
compute_correction_v2_chain_proportionalityandcompute_correction_v2_chunk_sizekeep their names. Renaming them would drop the production overrides currently set against those keys.doc/developer/generated/still documentscorrection_v2and the removed dyncfgs. That tree is regenerated by the documentation agent, so it is untouched here.Release notes
This release will not change any user-visible behavior.
🤖 Generated with Claude Code