2 [Utility.Event] ISCLOG: WebSocket [SendAsyncMessage]

The log text shows that SendAsyncMessage is trying to use OpenServer on %CSP.WebSocket.1, and the returned error is:

ERROR #7953: No data present for WebSocketID '<id>' [1]

From the WebSockets tutorial, OpenServer(WebSocketID) is used when the application keeps track of active WebSocket IDs and later reopens the server-side connection for asynchronous writes. In the example, the IDs are stored during OnPreServer() in a global, and later SendData() loops through those stored IDs and calls ws.OpenServer(c) before writing to the client. [2][3]

The same tutorial also shows the expected cleanup path when a client closes the WebSocket: in Server(), when Read() returns the $$$CSPWebSocketClosed condition, the code removes the corresponding WebSocket ID from the storage (kill ^Chat.WebSocketConnections(..WebSocketID) in one version, or kill ^CacheTemp.Chat.WebSockets(..WebSocketID) in another) and then exits. [2][3][4]

So, based on the retrieved material, the practical analysis is:

1. Your application is using asynchronous WebSockets, because OpenServer()/SendAsyncMessage is part of that pattern. [2][3]
2. The failing WebSocket ID is being referenced later for a send, but there is no longer data for that WebSocket ID. The tutorial’s pattern implies this can happen if a client connection has already closed while your application still tries to send to the saved ID. [1][2][3]
3. The first place to check is where your code stores active WebSocket IDs and whether it always removes them when the socket closes. The example explicitly stores IDs in OnPreServer() and deletes them when $$$CSPWebSocketClosed is detected. [2][3][4]

Steps you can take to analyze and correct it:

• Find the %CSP.WebSocket server class used in namespace ACB, and review where it records ..WebSocketID values for later sends. The tutorial shows this is commonly done in OnPreServer(). [1][2][3]
• Review the Server() method and confirm it handles the closed-socket case returned by Read(), specifically the $$$CSPWebSocketClosed path, and removes the stored WebSocket ID. [2][3][4]
• Review the code that broadcasts or pushes messages, especially any loop that iterates saved WebSocket IDs and calls OpenServer() and Write(). That is the area directly matching your stack trace (OpenServer called from SendAsyncMessage). [1][2][3]
• If your application keeps WebSocket IDs in globals or another registry, verify that stale IDs are not left behind after browser/window/session disconnects. The examples show that stale IDs should be deleted on close. [2][3][4]

The retrieved material also shows that asynchronous operation depends on setting SharedConnection=1 in OnPreServer(). [2][3][4]

There is not enough information in the retrieved documents to say whether this is caused by browser disconnects, application cleanup logic, Web Gateway behavior, or another product defect in your specific environment. But the returned documents do support checking for stale stored WebSocket IDs and verifying cleanup on $$$CSPWebSocketClosed as the main corrective path. [2][3][4]

Sources: