Description
Describe the Feature
This is one of the most requested features, and there are several related issues that I will link to this issue, which will help manage the commits, discussions, etc. surrounding it.
Please leave any comments on this issue.
The problem with simply reconnecting and then re-subscribing is that any new incoming events must be stalled until a getLogs is used to backfill any events that occurred since the time that the node disconnected and the new subscription has been established. This is compounded by the problem where the reconnection fails frequently, since the disconnect is often due to the backend throttling the subscriber.
Most of the stubs are already in place to handle this, as it was a planned feature since before v6 was released. The goal is not to affect the current Subscriber API, but there may be some changes necessary. This issue will be kept up to date for those that have custom Subscriber implementations for alternative transports, please keep and eye (and subscribe) to this issue. :)
Code Example
No response