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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
//! 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.
//!
//! [`generation`] is that serving generation — the engine and the channel
//! estate built from the same rows — and the handle that publishes it. It
//! lives here for the same reason [`tasks`] does: it belongs to the node, and
//! it is injected *downward* into `engine`, `channel`, `kafka` and `queue`
//! rather than reaching up into any of them.
//!
//! [`model_admission`] is the worker behind the model routes: it drains the
//! admission queue the node holds, resolving each job's storage connector
//! from the registry and recording the verdict through the repository — the
//! two things `model::admission` deliberately takes as parameters.
//!
//! [`models`] is the generation-side of the model subsystem: the quarantine
//! of a workflow that names a model the generation cannot serve — the same
//! treatment a workflow naming an unavailable plugin function gets — and the
//! preload that warms what a published generation will run. Both need the
//! channel rows, the workflow rows and the node's live components, which is
//! why they are here and not in `model/`.
//!
//! [`reload`] rebuilds that generation, and restarts the Kafka consumer that
//! rides along with it. 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, rebuilds the channel estate and restarts a Kafka
//! consumer, and the engine is one of the things it swaps. Here it depends
//! downward on all of them.
pub use ;
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.
/// Every handler an engine built from this node's live components carries:
/// Orion's own, with the Kafka publisher swapped in when a producer exists.
///
/// The one assembly boot, reload and the test endpoint share. A reload that
/// must rebuild the engine — the plugin set changed, so `with_new_workflows`
/// cannot carry the old handler map across — used to have no way to
/// reproduce what boot registered; this is that way.