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

  1. Do not resume during or after shutdown; gate resume behind your shutdown barrier and check handle.is_done() first
  2. If the system is gone, re-dispatch the task on a new system instead of resuming (shutdown returns task objects via TaskStatus::Shutdown)
  3. Order usage: resume while alive, shutdown last, drop runtime after
  4. 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

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


AI-assisted analysis of spacedriveapp/spacedrive@6dfeccf211 (2026-08-16). Data as JSON: /api/errors/aaa80e4e06e99d6d. Report an issue: GitHub.