Does web3.js v4 retain built-in WebSocket reconnection logic, or is it entirely delegated to the application layer?

The web3.js v4 release restructured the provider abstraction to comply with EIP-1193 and support modular transports, including WebSocket. The migration guide marks the legacy WebSocketProvider deprecated, but the new Provider interface does not specify whether built-in WebSocket reconnection is retained or fully delegated to applications. This ambiguity affects dApps migrating from v1.x, where WebSocket subscriptions previously required explicit teardown to prevent memory growth under subscription churn.

Key constraints include the absence of a drop-in reconnection strategy in the v4 Provider interface, the deprecation of WebSocketProvider, and the need for application code to manage socket lifecycle when upgrading. Additionally, the .clearSubscriptions() method exists only on the WebSocketProvider instance, not on the top-level web3 object, so code using web3.eth.subscribe() must retain a provider reference during migration.

Questions left unanswered include: What reconnection guarantees, if any, does the v4 Provider abstraction provide for WebSocket transports? When will the library team publish a definitive reconnection strategy, and will it be backward-compatible with v1.x subscription patterns? How should dApps currently relying on v1.x WebSocket semantics migrate subscriptions without built-in reconnection support?