Timed-out search tasks can continue running after Qui marks them complete

[mrsJedi]

Description

Summary

I found a cancellation-lifecycle defect in Qui v1.25.0’s shared search scheduler.

executeTask starts task.exec(...) in a goroutine, then waits for either its result or context expiry. If the context expires first, Qui records the task as finished and removes it from the scheduler’s in-flight state without waiting for the task.exec goroutine to exit.

A downstream operation that does not return promptly after cancellation can therefore continue running after Qui considers the task complete, potentially retaining goroutines, connections, or file descriptors.

The scheduled cross-seed path reaches this scheduler through jackettService.Recent.

What happened?

All times below are CDT.

• 02:41: a scheduled cross-seed run started.
• 02:49:13: its last persisted progress update was recorded.
• ~02:51: Qui's process resources began rising.

Before the rise, Qui had approximately:

• 280 goroutines
• 46 open file descriptors
• 1.24 GiB resident memory

Before restart, it reached:

• 53,576 goroutines
• 53,247 open file descriptors
• 4.30 GiB resident memory

After restarting Qui, it returned to approximately:

• 114 goroutines
• 118 open file descriptors
• 1.29 GiB resident memory

What did I expect?

A timed-out task can report its timeout to the caller immediately, but Qui should retain ownership of that task until its execution goroutine has actually exited. It should not remove the task from inFlight or treat it as fully complete while its work is still running.

What actually happened?

The scheduler treated the task as complete immediately after context expiry, even though its execution goroutine could still be running.

I reproduced this against v1.25.0 with an isolated test using a short-lived context and a deliberately blocked task.exec function. When the deadline expired:

• Qui reported context deadline exceeded.
• executeTask returned.
• The task function remained blocked until explicitly released.

Steps to reproduce

1. Create a scheduler task with a short context.WithTimeout.
2. Make its task.exec signal that it started, then block without returning.
3. Run executeTask.
4. Let the task context expire.
5. Observe that the scheduler reports context deadline exceeded and returns before task.exec has exited.

Environment

- Qui: `1.25.0`
- qBittorrent: `5.2.3`
- Deployment: release binary managed by systemd; not Docker
- OS: Debian GNU/Linux 12 (bookworm), kernel `6.1.0-43-amd64`

Relevant logs

Sanitized nearby records:


2026-08-14T07:41:04Z WARN  Failed to search indexer: prowlarr returned status 410
2026-08-14T07:41:05Z WARN  Recent search returning partial results (timeout=56000ms)
2026-08-14T17:37:50Z INFO  reconciled interrupted automation runs


No panic or goroutine dump was captured before the restart, so I cannot identify the exact downstream request that remained blocked or claim this is the sole cause. The scheduler lifecycle defect itself is reproducible, and the incident timing and reset-on-restart behavior are strongly consistent with it.

Checklist

• I have searched existing discussions and issues
• I have checked the documentation