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
//! Core traits for interacting with backends
//!
//! The core traits and types for backends, responsible for providing sources of tasks, handling their lifecycle, and exposing middleware for internal processing.
//! The traits here abstract over different backend implementations, allowing for extensibility and interoperability.
//!
//! # Overview
//! - [`Backend`]: The primary trait representing a task source, defining methods for polling tasks, heartbeats, and middleware.
//! - [`TaskSink`]: An extension trait for backends that support pushing tasks.
//! - [`FetchById`], [`Update`], [`Reschedule`]: Additional traits for managing tasks.
//! - [`Vacuum`], [`ResumeById`], [`ResumeAbandoned`]: Traits for backend maintenance and task recovery.
//! - [`RegisterWorker`], [`ListWorkers`], [`ListTasks`]: Traits for worker management and task listing.
//! - [`WaitForCompletion`]: A trait for waiting on task completion and checking their status.
//!
//!
//! ## Provided Implementations
//!
//! The module includes several default backend implementations, such as:
//! - [`MemoryStorage`](memory::MemoryStorage): An in-memory backend for testing and lightweight use cases
//! - [`CustomBackend`](custom::CustomBackend): A flexible backend allowing custom functions for task management
//! - [`VecDequeBackend`](dequeue::VecDequeBackend): A simple in-memory backend that uses a `VecDeque` to store tasks.
//! - [`Persisted`](persistence::Persisted): A backend that drives a [`Persistence`](persistence::Persistence) instance to emit tasks
use ;
use crate::;
/// Finalizes an intermediate backend configuration into a concrete backend.
///
/// Used internally by workers
/// Provides utilities for working with futures
/// Persistence layer for managing workers, tasks and events
///
/// Provides the `Persistence` trait which eases making backends with predictable persistence
pub use *;
pub use *;
pub use *;
pub use *;
/// In-memory backend based on channels
/// In-memory dequeue backend
/// A task backend that drives task acquisition and lifecycle management for a worker.
///
/// A backend is responsible for:
///
/// - determining when it is ready to perform work;
/// - yielding available tasks;
/// - registering the worker's waker when no work is currently available; and
/// - completing any pending cleanup or acknowledgement work during shutdown.
///
/// In other systems, this abstraction may be called a queue, broker, or
/// consumer. The Backend abstraction is intentionally broader than a queue:
/// it may also manage acknowledgements, leases, heartbeats, subscriptions, and
/// other state associated with processing tasks.
///
/// The worker drives a backend by repeatedly polling [poll_ready], [poll_next],
/// and [poll_close] as appropriate. Implementations must not block inside these
/// methods.
///
/// # Polling
///
/// Backend methods follow the same conventions as [Future] and [Stream]:
///
/// - Poll::Ready means the operation can make progress immediately.
/// - Poll::Pending means the operation cannot make progress yet and the
/// implementation has registered the supplied waker.
/// - The implementation must arrange for the waker to be woken when polling
/// again may make progress.
///
/// A backend should avoid busy-polling. In particular, [poll_next] should
/// return Poll::Pending once all currently available tasks have been drained
/// and wait for its underlying source to signal that more work is available.
///
/// # Shutdown
///
/// [poll_close] is called when the worker is shutting down. It should continue
/// making progress until all backend-owned resources and pending operations
/// have been released. A backend must not report completion from poll_close
/// while work that it is responsible for flushing or releasing remains.
///
/// [poll_next]: Backend::poll_next
/// [poll_ready]: Backend::poll_ready
/// [poll_close]: Backend::poll_close
/// [Future]: std::future::Future
/// [Stream]: futures_core::Stream
/// Decorates a backend with middleware, configuration and associated types
/// Provides wire-format support for a backend.
///
/// A `WireFormatBackend` associates a backend with a codec used to encode and
/// decode tasks and with the compact representation used when tasks are
/// transmitted or persisted in their encoded form.
/// Allows fetching a task by its ID
/// Allows updating an existing task
/// Allows rescheduling a task for later execution
/// Allows cleaning up resources in the backend
/// Allows resuming a task by its ID
/// A [`Backend`] that can be fallibly constructed from its own configuration.