Per-user queue priorities and fair-share scheduling for multi-user mode

[MAY4VFX]

Use Case

We run SwarmUI in a VFX studio environment with multiple artists sharing a common GPU render pool. Currently, the queue is strictly FIFO — whoever submits first gets processed first, with no way to differentiate between urgent production renders and casual experimentation.

This creates real problems:

• A junior artist experimenting with 50 variations blocks a senior artist who needs one critical render for a client deadline
• No visibility into queue position or estimated wait time
• Supervisors have no way to reprioritize work without manually asking people to cancel jobs

Related Issues

• Canceling Generation Interrupts All Active Sessions and Clears Queue (Multi-User Mode) #781 (Cancel interrupts all sessions) — highlighted the lack of per-user session isolation. While that specific issue is now closed, the underlying multi-user queue management is still basic.
• Public Call For Security Researchers -- Swarm Multi User System #679 (Multi-user security call) — the multi-user system is actively being improved; queue management is a natural next step.

Proposed Features

1. Per-user priority levels

Add an integer Priority field to T2IBackendRequest. Higher priority requests get dequeued first. Default priority = 0 preserves current FIFO behavior for existing single-user setups.

Priority could be:

• Set per-user by admin (e.g., lead artists get higher priority)
• Set per-role via the existing permission system
• Optionally adjustable per-request via UI

2. Fair-share scheduling (optional)

When multiple users have the same priority level, distribute GPU time fairly using round-robin or weighted fair queuing instead of pure FIFO. This prevents one user from monopolizing the queue with a large batch.

Example: User A submits 100 images, then User B submits 5. Currently B waits for all 100. With fair-share, they’d alternate (or use weighted interleaving).

3. Queue visibility API

A /API/QueueStatus endpoint returning:

• Current queue depth per user
• Estimated position / wait time
• Active generations and their owners
• Ability for admins to see the full queue

This enables building dashboards for studio supervisors.

4. Per-user cancel isolation

Building on #781 — ensure that cancel operations are scoped to the requesting user’s session. Admins could have a "cancel all" capability, but regular users should only cancel their own jobs.

Implementation Approach

I’ve looked through the codebase and believe the changes would be primarily in:

• src/Backends/BackendHandler.cs — replace ConcurrentQueue with a priority-aware structure in RequestHandlingLoop
• src/WebAPI/BackendAPI.cs — add queue status endpoint
• Session/permission system — add priority settings per user/role

I’m happy to submit a PR for this. Before I start coding, I wanted to check:

1. Is this something you’d be open to merging? I want to make sure the approach aligns with your vision before investing time.
2. Any architectural preferences? For example, should priority be a user-level setting, a role-level permission, or both?
3. Should I start with a minimal PR (just priority field + priority queue, no UI) and expand from there?

Happy to follow whatever code style and approach works best for the project. Thanks for building such a great tool!

[mcmonkey4eva]

re (1) this is a good request, please put it on Issues -> Feature Request, should be easy, pending detail discussion in the issue or the discord PR will be welcome
re (2) this is also good but more complex, also put it on Issues -> Feature Request, will need more careful discussion prior to any PR
re (3) already a pending plan
re (4) already implemented well to my knowledge