Module capture 

Finding the two restore inputs that live on a node’s disk, and naming the capture they are written into.

Neither file has a stable name. The RLMM snapshot does — it is always <log.dir>/remote-log-metadata/snapshot — but the controller metadata checkpoint is <end-offset>-<epoch>.checkpoint and there are several of them, in one of two directories under the metadata log directory, depending on whether the node runs a controller. Picking the right one is this module’s whole job, and it is a pure function over directory listings so a test can pin the choice without a broker.

Structs

CheckpointId

The identity of a metadata checkpoint, as its file name encodes it.

MetadataCheckpoint

A metadata checkpoint file and the id its name encodes.

Constants

CONTROLLER_CHECKPOINT_DIR

Where a node that runs a controller keeps its metadata checkpoints, under the metadata log directory: Kafka’s metadata partition directory.

OBSERVER_CHECKPOINT_DIR

Where a broker-only node keeps the checkpoints its metadata observer wrote, under the metadata log directory.

RLMM_SNAPSHOT_RELATIVE

The RLMM snapshot’s path under a log directory.

Functions

capture_id

The id a capture taken at now_ms carries, which is also its directory name inside the archive.

capture_key

The archive-relative key of one artifact inside one capture.

checkpoint_id

The CheckpointId a checkpoint file name encodes, or None when the name is not a checkpoint.

file_names

Every file name directly inside dir. An absent or unreadable directory is an empty list: a node can lack either checkpoint directory, and that is not a failure.

holds_a_topic

Whether a checkpoint’s decoded records hold a topic.

newest_checkpoint

The newest checkpoint among names, by (end_offset, epoch).

newest_metadata_checkpoint

The newest metadata checkpoint under log_dir, the node’s metadata log directory, looking in the controller’s directory and then in the observer’s.