krabka_barrier/lib.rs
1//! Administers krabka barrier groups.
2//!
3//! A barrier group is a named set of topics. A coordinator injects an
4//! epoch-stamped marker into every partition of the set and publishes the
5//! resulting offsets as a cut, which is an exact and reproducible point in
6//! every one of those topics at once. This is the operator's side of that:
7//! define a group, trigger a cut, read the cuts back, and prove that the
8//! marker a cut names is really in the log.
9//!
10//! This is the `krabka barrier` command from the monorepo's `krabka-cli`. That
11//! crate also drives the gres layer, which is why it could not follow the
12//! broker into this repository. It is a library as well as a binary so tests
13//! call [`run_from_args`] in process: a test that spawns the binary needs a
14//! Cargo working tree to build it from, and a Bazel test sandbox has none.
15//!
16//! Every subcommand speaks one krabka-private api key, in the 1010 to 1014
17//! range. A JVM `AdminClient` cannot send those, which is why the cuts are also
18//! published to `__barrier_state` where any consumer can read them.
19
20mod broker_codes;
21mod cli;
22mod dispatch;
23mod report;
24mod verify;
25
26pub use self::{
27 cli::{Cli, Command},
28 dispatch::{run, run_from_args},
29 verify::{Mismatch, VerifyOutcome},
30};
31
32/// The exit code for a request the broker refused.
33const EXIT_REFUSED: i32 = 1;
34/// The exit code for a transport failure, where nothing is known about the
35/// request's outcome.
36const EXIT_UNREACHABLE: i32 = 2;
37/// The exit code for a cut whose log does not match what it claims.
38const EXIT_MISMATCH: i32 = 3;