Message lost on 2 separate connections to same URL

Start with the publish method and its ratchet\client\connect calls, then reproduce the two back-to-back publishes shown in the issue. Trace why the first message is ignored when separate connections use the same URL, and verify the behavior with both messages sent independently. Done means the cause is identified and both messages are reliably delivered, or the limitation is documented.

Using ratchet/pawl v0.4.1 and PHP 7.4

Implemented pub/sub client in PHP...

public function publish(string $user, string $group, string $message)
    {
        $hubUrl = $this->getHubUrl();
        $accessToken = $this->getAccessToken($user);
        $url = $hubUrl.'?access_token='.$accessToken;
        $this->user = $user;
        $this->group = $group;
        $this->message = $message;
        \ratchet\client\connect($url,['json.webpubsub.azure.v1'])->then(function($conn) {
            $sendMessage = [
                'type' => 'sendToGroup',
                'group' => $this->group,
                'data' => [
                    'message' => $this->message
                ]
            ];
            $sendMessageText = json_encode($sendMessage);

            $joingroup = [
                "type" => "joinGroup",
                "group" => $this->group
            ];            
            $joingroupText = json_encode($joingroup);
            $conn->send($joingroupText);
            $conn->send($sendMessageText);
            $conn->close();
        }, function ($e) {
            error_log("Could not connect: {$e->getMessage()}\n");
        });        
    }

This works great. However, if I send back-to-back messages, e.g.

    $pubSubService->publish('server','activity-queue',json_encode($queueEntry));
    $pubSubService->publish('server','agent-table',json_encode($agent));

The first message is always lost. I've fixed this by queuing up the messages to the same URL and sending them together on the same connection. A much better design, I admit.

At the same time, this should work. Why do back-to-back messages on separate connections to the same URL fail? It took me quite a while to find this. There are no error messages. The first messages is simply ignored.