1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
//! Process-level runtime concerns: the things that own a *node* rather than a
//! request.
//!
//! [`tasks`] supervises the long-lived background tasks. It lives here rather
//! than in `queue/` because it is not about traces: the trace dispatcher, the
//! persistence workers, the audit writer, the retention jobs and the cluster
//! epoch watcher are owned by four different modules, and "is every one of
//! them still alive?" is a question about the node.
//!
//! [`reload`] rebuilds the serving generation — engine, channel registry, and
//! the Kafka consumer that rides along with them. It was `engine::reload`, and
//! that was the largest of the upward dependency edges in the tree: a module
//! the whole request path sits *below* reached up into `server::state` for
//! `AppState` and into `bootstrap` for `start_kafka_ingest`. It is not an
//! engine concern — it reads the database, republishes the channel registry
//! and restarts a Kafka consumer, and the engine is one of the three things it
//! swaps. Here it depends downward on all of them.
pub use ;
pub use ;
/// Borrow the handler dependencies straight off a live `AppState`.
///
/// The dry-run engine in `POST /workflows/{id}/test` must be built from the
/// *same* registries and pools as the serving engine — a copy that drifted
/// would make dry-run results a lie about production.
///
/// This was `HandlerDeps::from_state` in `engine::handlers`, which meant the
/// engine — a module every request path sits below — named `AppState`. The
/// mapping is a runtime concern: it says which of the node's live components
/// a handler gets, and `engine` only has to accept them.