Name-Keyed Async Task Scheduler with Sequential Lanes, Cancel and Clear by Name

Create a task scheduler for asynchronous functions, built in the style of an event emitter. Each task is submitted under a name together with an async function. The scheduler must satisfy two rules:

• Tasks with the same name execute one after another: a task starts only after the previous task with that name has finished, and tasks with the same name run in the order they were scheduled.
• Tasks with different names execute concurrently and independently: a slow or failing task under one name never delays or affects tasks under another name.

Implement it in JavaScript or TypeScript. One possible starting interface, which you may extend if you explain why:

interface TaskScheduler {
 schedule(name: string, task: () => Promise<unknown>): void;
 on(event: string, listener: (payload: unknown) => void): void;
}

The interview continued with two follow-ups, given below as Parts 2 and 3.

Clarifying Questions

• Should schedule also return a promise for the task's result, or are results reported only through events? Which lifecycle events should the emitter publish?
• If a task rejects or throws, should the next task with the same name still run?
• Is there any limit on how many names may run at the same time?
• Can a task call back into the scheduler, for example to schedule another task under its own name?

Part 1 — Same-name order, cross-name concurrency

Implement schedule and the event interface so that both rules hold. Show exactly how the next task for a name gets started, including when the current task fails.

What This Part Should Cover

• Strict per-name ordering with no overlap, and full independence across names
• Starting the next task after both success and failure, including a synchronous throw
• Cleaning up per-name state once a name has nothing left to run
• How results and errors reach the caller: a returned promise, emitted events, or both

Part 2 — Cancel the running task by name

Add cancel(name): cancel the task currently running under name and move on to the next scheduled task with that name.

Clarifying Questions for this Part

• Must cancelling stop the task's actual work, or only stop the scheduler from waiting for it?
• What should the code that scheduled the cancelled task observe?

What This Part Should Cover

• The precise meaning of cancellation, and how a cooperative task learns about it
• Protection against the cancelled task's late settlement
• What the cancelled task's caller and the event listeners observe
• Behavior when nothing is running under that name

Part 3 — Clear all tasks by name

Add clear(name): clear all running and scheduled tasks with that name.

What This Part Should Cover

• Discarding the waiting tasks and settling or reporting each of them
• Cancelling the running task by reusing the Part 2 logic, in the right order
• Tasks scheduled during or after the clear
• Releasing the name's state afterwards