fix(desktop): keep draining the worker queue past a pre-aborted task
What & why
Fixes #9463.
drainQueue rejected a pre-aborted task and moved to the next slot, so the task queued behind it waited with no timeout until another task arrived. This copies the inner loop the host-service WorkerTaskRunner already has. No current caller passes a signal, so this cannot happen today.
How I tested it
Failing regression test with the existing MockWorker. The bug was first found by checking every order of events in a small model, then reproduced against the real code.
WorkerTaskRunner.test.ts: 6 pass, 0 fail.
Checklist
- PR title follows conventional commits (
type(scope): subject) -
bun run lintandbun run typecheckpass (CI fails on lint warnings too) - "Allow edits from maintainers" is checked on fork PRs
- I have signed the CLA (the bot asks on your first PR)
Summary by cubic
Fixes #9463: drainQueue rejected a pre-aborted task and moved to the next slot, leaving the next queued task stranded with no timeout until another task arrived to trigger another drain.
The slot now keeps pulling from the queue until it dispatches a task or the queue is empty, matching the inner loop the host-service WorkerTaskRunner already uses. No current caller passes a signal, so this can't happen today; a regression test covers the scenario.