A transaction goes through the following states while being handled by the URL Loading System (see here):
If the cache lookup fails (i.e. there is no cached data or the cached data cannot be used), the transaction will be blocked until a connection is available to handle the transaction and send out its request. The URL Loading System only has a small number of connections (e.g. 6) per host and a connection is only established when needed. When there is no available connection to the target host a new connection will be established (TCP + TLS or QUIC setup) during which time the transaction is blocked. When the maximum number of connections for a specific host has already been reached, no new connection will be established and the transaction will instead wait until one of the available connections become available.
In the HTTP 1 case, this can lead to transactions being blocked for a long time (head of line blocking, as demonstrated in the WWDC Session "Analyze HTTP traffic in Instruments"), if there are many parallel requests to the same host.
However, a transaction will only report a connection once it got to the "sending request" state. Before that, it is still waiting for a connection and none has been assigned to it, yet. So "No Connection" means the transaction wasn't scheduled on any connection, which usually indicates it failed before it ever got to the "Sending Request" state. And that usually means it failed during the blocked state.
Given that the other connections in your screenshot do not appear to be busy, it seems as if this is not an issue of the other connections being busy, but instead that no (working) connection exists to the host. The HTTP traffic instrument cannot visualize when a connection is closed again, but based on your description it seems like the previously existing connections to the same host got closed and establishing a new connection did not happen or did not work causing all subsequent transactions to fail.
