krabka_remote_storage/dump.rs
1//! [`RlmmCacheDump`] is a flat, owned snapshot of an
2//! [`InmemoryRemoteLogMetadataManager`](crate::InmemoryRemoteLogMetadataManager)'s
3//! cache. The topic-backed manager's on-disk snapshot uses it.
4//!
5//! An import of a dump does no lifecycle-transition validation, unlike the
6//! live mutation path. The dumped states are already the product of valid
7//! transitions, so `add`/`update` would wrongly reject terminal states.
8
9use crate::metadata::{RemoteLogSegmentMetadata, RemotePartitionDeleteState, TopicIdPartition};
10
11/// Every partition's cache contents, flattened for snapshotting.
12#[derive(Debug, Clone, PartialEq, Eq, Default)]
13pub struct RlmmCacheDump {
14 /// One entry per partition that has any cached state.
15 pub partitions: Vec<PartitionDump>,
16}
17
18/// One partition's dumped cache: all of its segments (every lifecycle
19/// state, terminal included) plus its partition-delete state, if any.
20#[derive(Debug, Clone, PartialEq, Eq)]
21pub struct PartitionDump {
22 /// The partition this dump belongs to.
23 pub topic_id_partition: TopicIdPartition,
24 /// Every segment currently tracked for this partition, in no
25 /// particular order (import re-derives ordering / epoch index).
26 pub segments: Vec<RemoteLogSegmentMetadata>,
27 /// Partition-delete lifecycle state, if the partition was ever
28 /// marked for deletion.
29 pub delete_state: Option<RemotePartitionDeleteState>,
30}