Is is_shutting_down() returning true for paused workers intentional?

[Himmelschmidt]

I'm using pause() to temporarily halt a worker when authentication expires, intending to resume() once the user re-authenticates. However, I discovered that paused workers sometimes cannot be resumed:

1. is_shutting_down() returns true for paused workers (since it checks !self.is_running())
2. If in-flight tasks exist: resume() fails with ShuttingDown error (line 200 check)
3. If no in-flight tasks: the WorkerContext Future resolves (is_shutting_down() && task_count == 0), and the worker exits entirely

// Current implementation - treats Paused as "shutting down"
pub fn is_shutting_down(&self) -> bool {
    self.shutdown
        .as_ref()
        .map(|s| !self.is_running() || s.is_shutting_down())
        .unwrap_or(!self.is_running())  // <- Paused workers hit this
}

Is this intentional? If pause() is meant for very brief operational pauses only, what's the recommended pattern for temporarily halting a worker until an external condition is met?

I've worked around this in my fork by checking for Stopped state explicitly rather than !is_running(), but wanted to confirm before proposing a PR.

[geofmureithi]

This might be a bug, could you specify the specific version you are using?

…

On Thu, 18 Dec 2025, 01:28 Himmelschmidt, ***@***.***> wrote: I'm using pause() to temporarily halt a worker when authentication expires, intending to resume() once the user re-authenticates. However, I discovered that paused workers sometimes cannot be resumed: 1. is_shutting_down() returns true for paused workers (since it checks !self.is_running()) 2. If in-flight tasks exist: resume() fails with ShuttingDown error (line 200 check) 3. If no in-flight tasks: the WorkerContext Future resolves (is_shutting_down() && task_count == 0), and the worker exits entirely // Current implementation - treats Paused as "shutting down"pub fn is_shutting_down(&self) -> bool { self.shutdown .as_ref() .map(|s| !self.is_running() || s.is_shutting_down()) .unwrap_or(!self.is_running()) // <- Paused workers hit this} Is this intentional? If pause() is meant for very brief operational pauses only, what's the recommended pattern for temporarily halting a worker until an external condition is met? I've worked around this in my fork by checking for Stopped state explicitly rather than !is_running(), but wanted to confirm before proposing a PR. — Reply to this email directly, view it on GitHub <#647>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWXVRGWOGHMJSNKUETPLTPL4CHKKPAVCNFSM6AAAAACPLUXXLWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGI2TQMJZGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Himmelschmidt]

v1.0.0-beta.2

[geofmureithi]

Converted to Issue, please do a PR

[geofmureithi]

Resolved in #651
Thanks @Himmelschmidt