CockroachDB 24.1.2 documents changefeed restart correctness
July's maintenance notes include the initial-scan checkpoint repair and stricter Pulsar sink validation. They distinguish preserving emitted data from optimizing duplicate reduction.
An optimization that reduces duplicate messages has a different correctness obligation from a checkpoint that determines which data can be skipped. The CockroachDB 24.1.2 release notes, dated July 2, include both concerns. They describe the initial-scan checkpoint restoration repair and record disabling an optimization for duplicate reduction during aggregator restarts because of poor performance.
The checkpoint defect is already covered by the June 17 advisory A-123371. That advisory identifies a fix in the 24.1 release-candidate line and recommends repaired releases including 24.1.0. July's notes should therefore not be read as the first disclosure of the defect or as proof that every earlier final 24.1 release lacked its repair.
I value CockroachDB's consistency model, while treating a changefeed's emitted data as a separate thing to establish. Source transactions can be correct even when restart bookkeeping gives a consumer an incomplete copy. The useful information in these maintenance notes is the operation and progress state involved, not merely that a changefeed bug was fixed.
Restart progress must describe completed work
The initial-scan defect could occur when a changefeed restarted after persisting a checkpoint but before finishing its scan. Restoring checkpoint progress could advance spans that had not actually been scanned. The job could then omit events, producing an incomplete initial dataset. The repair prevents that incorrect advancement of unfinished work.
The advisory names initial_scan = 'yes' and initial_scan = 'only' as affected modes. It also identifies a nondeterministic span-processing condition needed to trigger the defect. That is narrower than saying every restarted feed loses events. The persisted checkpoint and incomplete scan are necessary parts of the reported path.
Long scans and large target tables increase the opportunity for that combination. Multiple target tables with different row counts can also contribute, as can frequent checkpointing and the shutdown-checkpoint setting. July's notes preserve those factors alongside the repair. They explain why a feed that starts and completes quickly is not an adequate model of every restart condition.
The completed-scan symptom is particularly important. A job reporting completion does not establish that all target rows reached the consumer when its progress accounting is itself incorrect. That follows from the mechanism, since the incorrect state is what allows unscanned work to be treated as already completed.
Duplicate reduction is a separate optimization
The release-branch merge referenced by the notes includes the earlier work disabling the aggregator drain watcher by default. Its description explains that orderly shutdown and updated frontier information had been intended to reduce duplicates during node restart. The same history also includes the checkpoint correctness repair.
It is useful to retain both facts without merging their meanings. Disabling an optimization because of poor performance concerns how much work or delay it introduces. Repairing incorrect progress restoration concerns whether the consumer receives the required events. A release can carry both changes, but they answer different questions about restart behavior.
The recorded history also explains why the July changelog contains references to work developed earlier. The referenced merge carries release-candidate changes into the maintenance branch. A changelog entry's presence in 24.1.2 does not by itself identify the first artifact that contained its code. The advisory gives more specific information about the checkpoint fix's availability.
I prefer reading those sources together when deciding what a release note means. The release identifies the maintained version and included changes. The advisory supplies affected ranges and repaired versions for the specific defect. Neither needs to be stretched into a stronger chronology than it actually states.
Sink options should fail explicitly when unsupported
Version 24.1.2 also adds error messages for unsupported Apache Pulsar sink parameters. The notes give topic_prefix is not yet supported as an example. This is a configuration-validation improvement. It lets the database identify that a requested sink behavior is unavailable instead of leaving the option's status unclear.
The distinction matters because sink configuration contributes to the consumer's interpretation of a feed. A parameter that controls naming or routing cannot safely be assumed effective merely because a broadly similar sink accepts it. The release identifies a concrete unsupported option, so applications should read support in terms of the selected sink rather than extrapolate from another connector.
The same maintenance release fixes a panic involving changefeed.aggregator.flush_jitter with min_checkpoint_frequency set to zero. That is another specific configuration combination, distinct from the initial-scan data omission. A panic, an unsupported sink option and incorrect checkpoint progress have different symptoms even though all occur within changefeed operation.
The July notes consequently provide several precise boundaries around restart and configuration behavior. The checkpoint repair preserves unfinished initial-scan work, while explicit sink errors identify unsupported requests. Those details let an operator distinguish missing-data exposure from an execution failure or a configuration the selected sink cannot implement.