# Expected Diagnosis: checkpoint-catchup-slow-after-changefeed-resume

The expected result should converge on the case-specific mechanism below while
keeping conclusions bounded by the collected evidence.

## Expected conclusion

The v8.5.7-release.1 storage sink flushed only one hard-coded batch of 4096 events per interval. At roughly 2000 DML/s, each flush advanced checkpoint-ts by only about two seconds, so backlog accumulated even after resolved-ts recovered. A long flush interval amplified the lag. The formal v8.5.7 build writes multiple batches; lowering flush interval is a mitigation.

## Required evidence chain

- Separate resolved-ts recovery from checkpoint-ts persistence and quantify the roughly two-second advance per flush.
- Identify the hard-coded 4096-event storage-sink batch limit in the incident build.
- Explain why the incoming DML rate exceeds effective flush throughput and why a 60s or 300s interval magnifies lag.
- Recommend the formal v8.5.7 multi-batch fix and reducing flush interval while validating worker sizing for many tables.