pub struct InboxDoc {
pub entries: Vec<InboxEntry>,
pub window: Option<Window>,
pub boundary_request: Option<VerbRequest>,
pub sync_request: Option<VerbRequest>,
pub removals: Vec<Removal>,
}Fields§
§entries: Vec<InboxEntry>§window: Option<Window>§boundary_request: Option<VerbRequest>“Please publish” from outside the pod (§2.5). Deliberately a
FIELD and not a fake no-object InboxEntry: consume_inbox
HEADs file_key(path) for every entry, so an entry naming no
object lands in the NotFound arm as a spurious
consume-object-missing conflict — and special-casing the
single most safety-critical function in the crate to avoid that
is worse than either.
sync_request: Option<VerbRequest>“Please pull” from outside the pod — CARRIED, never performed
(D14). A boundary publishes what is already on disk and touches
no local file; sync re-derives the tree against the current
remote manifest and DELETES local files for remotely-deleted
paths. Performing that on a remote’s say-so would upgrade what a
leaked gateway bearer can do from “publish, plus hand over these
N named objects” to “rewrite and delete across a running agent’s
tree, at my timing, under a scope I choose”.
removals: Vec<Removal>DECLARED removals, pending or refused (see Removal). At most
one per path: a newer removal of a path supersedes an older one.
Implementations§
Source§impl InboxDoc
impl InboxDoc
Sourcepub fn pending_removal(&self, path: &str) -> Option<&Removal>
pub fn pending_removal(&self, path: &str) -> Option<&Removal>
A removal of path that is recorded and not yet performed nor
refused — what a listing built over the manifest and the inbox
subtracts, so a deleted or renamed-away file leaves the UI the
moment the removal is recorded rather than when the syncer gets
to it.