spacedriveapp/spacedrive · error
System channel closed trying to resume task
Error message
System channel closed trying to resume task
What it means
SystemComm::resume_task (system.rs:509) spawns a detached task sending a ResumeTask message to the system loop; the .expect at system.rs:525 panics when the system channel is closed. It runs when TaskHandle::resume/TaskRemoteController::resume (task.rs:536) forwards the resume to the system. The ack oneshot is moved into the unsent message, so its drop cascades into the caller panic 'Worker failed to ack resume request' (task.rs:539).
Source
Thrown at crates/task-system/src/system.rs:525
}
pub fn resume_task(
&self,
task_id: TaskId,
task_work_table: Arc<TaskWorktable>,
ack: oneshot::Sender<Result<(), SystemError>>,
) {
let system_tx = self.0.clone();
spawn(
async move {
system_tx
.send(SystemMessage::ResumeTask {
task_id,
task_work_table,
ack,
})
.await
.expect("System channel closed trying to resume task");
}
.in_current_span(),
);
}
pub fn force_abortion(
&self,
task_id: TaskId,
task_work_table: Arc<TaskWorktable>,
ack: oneshot::Sender<Result<(), SystemError>>,
) {
let system_tx = self.0.clone();
spawn(
async move {
system_tx
.send(SystemMessage::ForceAbortion {
task_id,
task_work_table,View on GitHub (pinned to 6dfeccf211)
Solutions
- Do not resume during or after shutdown; gate resume behind your shutdown barrier and check handle.is_done() first
- If the system is gone, re-dispatch the task on a new system instead of resuming (shutdown returns task objects via TaskStatus::Shutdown)
- Order usage: resume while alive, shutdown last, drop runtime after
- Library fix: has_shutdown guard in SystemComm plus SystemError propagation instead of .expect
Example fix
// before
if let Ok(handle) = dispatcher.dispatch(task).await {
handle.pause().await?;
system.shutdown().await;
handle.resume().await?; // resume after shutdown -> system channel closed -> panic chain
}
// after
if let Ok(handle) = dispatcher.dispatch(task).await {
handle.pause().await?;
handle.resume().await?; // resume while the system loop is alive
system.shutdown().await;
} Defensive patterns
Strategy: validation
Validate before calling
// Resume only inside the live window.
if !shutting_down.load(Ordering::Acquire) && !handle.is_done() {
handle.resume().await?;
} else {
// system gone: recover the task object from TaskStatus::Shutdown and re-dispatch later
} Try / catch
use futures_util::FutureExt; use std::panic::AssertUnwindSafe;
// isolates the follow-up 'Worker failed to ack resume request' panic at the controller
if AssertUnwindSafe(handle.resume()).catch_unwind().await.is_err() {
tracing::warn!(task = %handle.task_id(), "resume lost: task system shutting down");
} Prevention
- Never resume during or after System::shutdown
- Do not hold TaskRemoteController clones across shutdown expecting them to work
- Model resume-after-restart as re-dispatch of the recovered task, not handle.resume()
When it happens
Trigger: Calling handle.resume() after System::shutdown() completed or racing it; resuming a paused/queued task while the Tokio runtime is being dropped so the system loop's receiver no longer exists.
Common situations: Job-manager code resuming paused jobs during shutdown; UI resume actions pressed while the app is closing; tests resuming after the runtime began teardown.
Related errors
- System channel closed trying to report working
- Worker channel closed trying to pause a not running task
- Worker channel closed trying to cancel a not running task
- Worker channel closed trying to force task abortion
- Worker channel closed trying to shutdown
AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16).
Data as JSON: /api/errors/aaa80e4e06e99d6d.
Report an issue: GitHub.