Skip to content

Task 20: WebSocket Setup Pollutes Global Scope and Cannot Be Cleanly Reconnected #316

Description

@grantfox-oss

The current implementation of the websocket client hardcodes the socket instantiation logic (new WebSocket()) and all event listeners (ws.on('message')) directly in the global, top level scope of the script. While this works for a naive, single run execution, it is fundamentally incompatible with advanced connection management. If the connection drops and needs to be re established, the script cannot cleanly instantiate a new socket without polluting the global scope with duplicate event listeners and lingering memory references from the dead socket. This architectural flaw prevents the script from achieving long term stability.

Issues/what to fix

The entire WebSocket setup process must be completely refactored. All socket initialization logic, along with the binding of the message, open, error, and close event listeners, must be meticulously wrapped inside a discrete, callable class method or a factory function (e.g., function connectToTraceStream()). By isolating the connection lifecycle within a functional boundary, the script gains the ability to cleanly instantiate, track, and gracefully garbage collect discrete socket instances. It allows the system to easily tear down old, broken sockets before attempting to spawn fresh connections.

Files location

examples/api clients/websocket client/index.js

Expected result

The WebSocket codebase will be highly modularized and encapsulated. Global state pollution will be eradicated, drastically improving code maintainability and paving the way for the implementation of advanced, memory safe connection management logic.

Contributor telegram group

https://t.me/+sII7WPhll2liMGNk

Metadata

Metadata

Labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions