Skip to content

compute: remove the correction v1 buffer - #38484

Open
antiguru wants to merge 2 commits into
MaterializeInc:mainfrom
antiguru:remove-correction-v1
Open

compute: remove the correction v1 buffer#38484
antiguru wants to merge 2 commits into
MaterializeInc:mainfrom
antiguru:remove-correction-v1

Conversation

@antiguru

Copy link
Copy Markdown
Member

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 removes 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 flags themselves still need archiving in LaunchDarkly.

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.

doc/developer/generated/ still documents correction_v2 and 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

antiguru and others added 2 commits August 26, 2026 13:14
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>
@antiguru
antiguru requested a review from DAlperin August 26, 2026 11:19
@antiguru
antiguru marked this pull request as ready for review August 26, 2026 14:51
@antiguru
antiguru requested review from a team as code owners August 26, 2026 14:51
@antiguru
antiguru requested a review from petrosagg August 26, 2026 14:51
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.

1 participant