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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
//! Bounded dispatch for the crate's best-effort background indexing work
//! (issue #2798).
//!
//! Why: [`crate::search_index::index_files_best_effort`] used to call
//! `std::thread::spawn` once per write/edit tool call with nothing capping how
//! many of those threads could be alive at once. Against a *degraded but
//! reachable* trusty-search daemon each thread lives far longer than usual —
//! #2785's bounded retry means up to ~6.2s per file (3 attempts × a 2s client
//! timeout, plus backoff) — so a burst of writes spawns threads faster than
//! they drain and the process accumulates them without limit. Nothing in the
//! old path pushed back, which is exactly why a slow daemon turned into
//! unbounded resource growth in the client.
//!
//! What: a fixed-size worker pool fed by a BOUNDED queue. At most
//! [`MAX_INDEX_WORKERS`] jobs run concurrently and at most
//! [`INDEX_QUEUE_CAPACITY`] more wait behind them. Submission never blocks the
//! caller (a tool executor mid-turn), so the saturation behaviour is the third
//! option: **the batch is REJECTED**. Rejection is counted
//! ([`BoundedDispatcher::rejected`]) and the caller logs at `warn` naming what
//! it dropped — see [`crate::search_index::index_files_best_effort`]. Blocking
//! was rejected as a design because it would convert a slow daemon into a
//! stalled agent task, the precise failure the whole fail-open module exists to
//! avoid; an unbounded queue was rejected because it only moves unbounded
//! growth from threads to memory.
//!
//! Queued work is not stale work: each job reads the file's content from disk
//! at EXECUTION time, so a batch that waits in the queue indexes whatever the
//! file says when it finally runs.
//!
//! The bound loses work in TWO places, and this module counts both because a
//! health consumer must be able to tell them apart. A SUBMISSION the pool
//! refuses is a rejection ([`BoundedDispatcher::rejected`]) — the pool was full,
//! and nothing of that batch ran. A batch the pool ACCEPTED and started, then
//! cut short at [`crate::search_index::BATCH_INDEX_BUDGET`], is a truncation
//! ([`BoundedDispatcher::truncated`]) — part of it landed and the rest was
//! abandoned. The two have different causes and different fixes (a full pool
//! vs. a slow daemon making one batch overrun), so they are never summed into
//! one number.
//!
//! Test: `dispatcher_rejects_submissions_once_workers_and_queue_are_full`,
//! `no_more_jobs_run_concurrently_than_the_worker_count`,
//! `a_panicking_job_does_not_kill_its_worker`, `a_fresh_pool_reports_no_drop_ever`,
//! `a_rejection_records_when_it_happened`,
//! `a_truncation_is_counted_apart_from_a_rejection` (in the `tests` module
//! below), and the end-to-end
//! `index_files_best_effort_drops_the_batch_when_the_shared_pool_is_saturated`
//! in `search_index_tests.rs`.
use AssertUnwindSafe;
use ;
use ;
use ;
/// A unit of background indexing work.
pub type IndexJob = ;
/// How many indexing jobs may run at once, process-wide.
///
/// Why: four concurrent per-file POSTs is more than enough to keep a healthy
/// local daemon busy, and it is a hard ceiling on the OS threads a degraded one
/// can tie up. Test: `no_more_jobs_run_concurrently_than_the_worker_count`.
pub const MAX_INDEX_WORKERS: usize = 4;
/// How many batches may wait behind the busy workers before submissions are
/// rejected.
///
/// Why: deep enough that a realistic write burst (the #2798 bake-off did ~29
/// files over 13.5 minutes) never reaches it, shallow enough that a wedged
/// daemon cannot grow the backlog without limit. Test:
/// `dispatcher_rejects_submissions_once_workers_and_queue_are_full`.
pub const INDEX_QUEUE_CAPACITY: usize = 64;
/// How many times one kind of work loss has happened, and when the last one was.
///
/// Why: both loss modes in the module doc need exactly this pair, and a health
/// consumer needs both halves — the total says whether it has EVER happened,
/// the stamp says whether it is happening NOW. One type so the two halves
/// cannot drift apart, and so a later loss mode inherits the shape instead of
/// growing a third near-copy of `fetch_add` + `SystemTime::now`.
/// What: `count` is monotonic for the life of the process. `last_unix_secs`
/// stores `0` until the first [`LossCounter::record`], which is why
/// [`LossCounter::last_unix_secs`] hands back an `Option` rather than leaking
/// that sentinel to callers.
/// Test: `a_fresh_pool_reports_no_drop_ever`,
/// `a_rejection_records_when_it_happened`,
/// `a_truncation_is_counted_apart_from_a_rejection`.
pub
/// A fixed worker pool with a bounded queue, rejecting work when both are full.
///
/// Why / What / design rationale: see the module doc, including why the two
/// loss counters below stay separate numbers.
/// Test: the module's `tests` submodule constructs small instances
/// (`BoundedDispatcher::new(1, 1)`) so the saturation boundary is exercised
/// deterministically rather than by racing the shared pool.
pub
/// Drain jobs until the sender is gone, surviving a panicking job.
///
/// Why: a job that panics must not silently retire a worker — losing all
/// [`MAX_INDEX_WORKERS`] that way would turn every later submission into a
/// rejection, converting the bound into a permanent outage.
/// What: locks the shared receiver only for the `recv` itself (so the other
/// workers can take the next job while this one runs), then executes the job
/// inside `catch_unwind`, logging a panic at `warn`. A poisoned mutex is
/// recovered rather than propagated. Returns when the channel disconnects.
/// Test: `a_panicking_job_does_not_kill_its_worker`.
/// The process-wide pool every incremental index update flows through.
///
/// Why: the bound only means anything if it is SHARED — a per-call pool would
/// reproduce the unbounded spawn it replaces. Lazily initialised so a process
/// that never indexes pays for no threads.
/// What: a `OnceLock`-backed [`BoundedDispatcher`] sized
/// [`MAX_INDEX_WORKERS`] × [`INDEX_QUEUE_CAPACITY`].
/// Test: `index_files_best_effort_drops_the_batch_when_the_shared_pool_is_saturated`.
pub
// Tests live in a sibling file so this module stays well under the 500-SLOC
// production cap; as a child module it still reaches private items via `super::`.