Operating System

Windows 11 x64

Programming Language

C#

CCXT Version

4.5.84

Description

This is separate from the client-identity race fixed by #30545.

Affected file(s)

• cs/ccxt/ws/Client.cs (connect, Connect, onOpen, PingLoop, Receiving, reset, Close)
• cs/ccxt/ws/Exchange.WsBridge.cs (CleanupClients)

Steps to reproduce

No exchange credentials or network connection are required for the first case:

var client = new BaseExchange.WebSocketClient("ws://localhost:1234", null, (c, m) => { });
client.rejections["orphan"] = new NetworkError("orphan");
await client.Close();
Console.WriteLine(client.rejections.Count); // 1 on v4.5.84
Console.WriteLine(client.connect().IsCanceled); // false on v4.5.84

For the transport case, create a local HttpListener WebSocket server, call client.connect(), then await client.Close() while the peer stays connected. The client starts its ping loop with async void and launches connect/receive through detached Task.Run calls; Close returns after CloseOutputAsync, without awaiting the receive or ping loops. Repeat close while a connection is pending and verify no background task can reopen or dispatch a frame after close. For the callback case, pass an onError delegate that throws and await client.Close(); on v4.5.84 the callback exception faults close before transport teardown.

Expected behavior

Close should be idempotent, stop and await client-owned connection, ping, and receive work, settle pending connection and watch futures, and clear orphaned subscriptions/rejections. A failed-client cleanup should shut down that same client's transport without removing a healthy replacement installed under its URL. A throwing error callback should not prevent the transport from being closed. A later connect should not start work on a retired client.

Actual behavior

Close invokes onError and sends a close frame if the socket is open, but does not cancel, track, await, or dispose the client-owned task graph. reset clears futures and subscriptions but leaves orphaned rejections. On a never-connected client, connect() after Close() returns an unsettled connection task and starts a new background dial. CleanupClients removes the errored client by reference (correctly preserving a replacement) but does not close that failed client's transport. Exceptions from the error callback propagate into Close or an async void ping path.

The first code sample deterministically exposes retained state and connect-after-close on the release. An offline in-process-server test can also check that closing a connected client waits for its receive loop to stop without exchange access. The existing upstream retirement and keepalive-timeout suites should remain green with a fix.

Root cause

connect and Connect launch nested untracked tasks; onOpen launches PingLoop as async void and Receiving on another untracked task. Neither connect nor receive uses a lifetime cancellation token. Close has no shared completion task and no task ownership boundary, while reset does not clear rejections. The error delegate is invoked without containment, and the bridge detaches an errored client without closing it.

Suggested fix

Give each client one guarded shutdown task and a cancellation token shared by connect, ping, and receive. Track those tasks; on close mark the client retired before new connection attempts, send the close output, cancel and await owned work, and release transport resources and orphaned state. Avoid awaiting the ping task from itself when a keepalive timeout initiates close; preserve the existing close-frame behavior and the #30545 remove-by-reference rule. Catch error-callback failures without logging credentials or preventing shutdown. Add offline tests for close-before-connect, close-during-connect, callback failure, failed-client shutdown, idempotence, and the existing keepalive/retirement races.