rqlite 8.43.4 connects change capture to delivery progress
August's CDC work connects event queues, leadership and delivery acknowledgements. The final patch removes a separate watermark file and reconstructs startup state from the queue.
A change stream needs to remember more than which rows changed. It also needs a rule for deciding which events the destination has already accepted, particularly when another database node takes over transmission. rqlite 8.43.4, published on 28 August, develops that part of its change-data-capture implementation through queue integration and high-watermark propagation.
The changelog includes both a change to persist a separate watermark file and a later change removing that persistence. Reading the final source resolves the apparent contradiction. Construction initializes the watermark from the persistent queue, so this release should not be described as preserving an exact delivery watermark in an independent JSON file.
I find this work interesting because rqlite already separates local SQL execution from replicated agreement. Sending changes outside the database introduces another distinct progress state. An external HTTP destination can accept an event at a different moment from the moment the database applies it.
The watermark describes cluster delivery
The released CDC service describes its high watermark as the index of the last event successfully sent to the webhook by the cluster. The sending node does not have to be the node currently reading that value. That definition is why delivery progress must move between nodes.
The leader's transmission loop advances the in-memory watermark after sending a batch successfully. The success condition shown in the HTTP path accepts either OK or Accepted responses. It assigns the index of the batch's last event group after that success.
That assignment records the service's delivery result. It does not inspect a downstream database or prove that an HTTP receiver has completed every asynchronous task it might perform after returning Accepted. The recipient's response contract and the sender's progress definition remain related but separate.
A periodic leader loop broadcasts a nonzero watermark to the cluster. It broadcasts even if the position has not advanced, while it avoids repeating queue pruning for an unchanged position. Repeated transmission of the same progress value helps nodes learn the current boundary without requiring another successful event batch.
Followers use progress to prune their queues
The follower loop receives watermark observations. It ignores zero and values that do not exceed the position it has already handled in that loop. An advancing value leads it to delete queued events through that position and update its in-memory watermark.
This establishes the purpose of the broadcast. Followers may hold events that another node has already delivered. Learning the cluster's delivery position lets them remove those events without transmitting them independently. A change of leadership can then operate on the remaining queue.
PR #2231 adds the cluster message used to carry these updates. It introduces an explicit high-watermark update request and response, together with service registration for receiving the update. This is application delivery metadata alongside the database's other inter-node communication.
The existence of that message should not be confused with a general guarantee of exactly-once external effects. The implementation has distinct steps for an HTTP response, an in-memory update, broadcast and queue deletion. A consumer's duplicate-handling policy cannot be inferred from the name of a watermark.
The final release removes the extra file
Earlier in development, PR #2242 writes watermark data to a JSON file with a temporary-file replacement sequence. It also adds a restart test for that representation. That patch explains the persistence entry in the changelog, but it is not the final design.
PR #2262 removes the file-reading and file-writing helpers. Construction instead asks the FIFO for its first key and uses that value to initialize the watermark. Its comment says queued events are assumed not to have been sent, and updates from other nodes can correct and prune the queue.
The distinction is material when the queue is empty. The new first-key method returns zero for an empty queue. A restart therefore does not necessarily recover the exact numeric value that an earlier service instance last reported. It recovers local queue state and can subsequently learn delivery progress from the cluster.
My preference is to describe that behavior directly. A durable event queue and a durable exact acknowledgement position are different promises. The final patch deliberately removes one independent representation, so documentation should follow the shipped constructor and queue operations.
Event envelopes carry origin information
PR #2221 also develops the HTTP event envelope with node identity, an optional service identifier and a timestamp around its payload. That metadata gives a receiver context beyond the row-change list itself. It reflects the fact that the stream has an emitting service and node as well as database changes.
The release collects this work under implementation changes, alongside tests of cluster behavior and failure injection. It is a substantial preparation of CDC delivery machinery. The most useful reading is the relationship among the durable queue, leader transmission and cluster progress updates, with startup behavior taken from the final released source.