## TL;DR
A stuck Grid 4 queue almost always means no node can satisfy the requested capabilities: browser version mismatch, wrong platform, or all slots busy with hung sessions. Check the Grid UI (or the `/status` endpoint) to compare queued requests against registered node stereotypes, then look for sessions that never released their slots. The fix is usually aligning browser versions, adding matching nodes, or killing orphaned sessions; raising queue timeouts only buys time.

## The query
```text
selenium grid 4 session queue stuck: how to debug
```

## Use this when
- Tests hang waiting for a Grid session
- The Grid UI shows a growing session queue
- New nodes register but the queue does not drain
- Sessions pile up after a deploy or browser upgrade

## Not for
- Local (non-Grid) driver startup failures
- Grid installation or networking setup
- Test logic failures once a session is running

## Steps
1. Open the Grid UI or query `/status` and compare each queued request's capabilities against node stereotypes. Expected output: you see the mismatch (e.g. requests want Chrome 130, nodes offer Chrome 128) or that all slots are occupied.
2. List active sessions and find ones that are idle or orphaned (started long ago, no commands flowing). Expected output: a set of stale sessions holding slots.
3. Delete orphaned sessions via the Grid API and align versions (update node browsers or pin requested versions). Expected output: slots free up and queued requests start matching nodes.
4. Re-run and watch the queue drain; add alerts on queue depth so it does not silently stall again. Expected output: queue depth returns to near zero and stays there during a full run.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3QCIinQXLs3vx2In4cOi0w