Module live_post_bundle_manager 

Production PostBundleManager — cache, fetch, heal

The real implementation of crate::client::post_bundle::post_bundle_manager::PostBundleManager used in production. Lookup proceeds in three stages:

1. Cache — check BUCKET_POST_BUNDLE in crate::client::client_storage::client_storage::ClientStorage. Serve hot entries immediately; serve stale entries only if the bundle is already sealed.
2. Network — otherwise a background walk visits peers closest to the bucket’s location id via a crate::client::peer_tracker::peer_iterator::PeerIterator, issuing GetPostBundleV1 RPCs, gated by the crate::client::caching::cache_radius_tracker to avoid re-hammering already-cached peers. Concurrent lookups for the same location share one walk. PostBundleManager::get_post_bundle answers as soon as the walk accepts its first authoritative bundle (a provisional answer); PostBundleManager::get_post_bundle_settled waits for the walk’s best-of-config::REDUNDANT_SERVERS_PER_POST answer.
3. Settle — once the walk has its quorum it caches the best bundle locally, then spawns crate::client::post_bundle::post_bundle_healing to reconcile divergent servers and uploads the original signed bundles to the servers that asked to cache them.

A provisional bundle is never stored or forwarded. Its posts and overflowed flag reflect only the bundles seen so far, so a timeline pass built on it may miss posts (or child buckets) that only later responders hold; anything fetched after the bundle settles sees the full picture.

Structs

LivePostBundleManager

The production PostBundleManager implementation — the one that actually talks to the network.