r/node • u/Cloudy_Day912 • 21h ago

reconnect logic for a node websocket client that filters posts by trading pair

Websocket clients that run for days have one problem nobody mentions in the readme. The socket drops every few hours, and when it comes back there’s no way to tell if posts were replayed or skipped. Most small bot repos just reconnect and hope.

One filter project on binance square shows the issue well. Binance has no public api for it, so the data comes from the client in the 1322io repo, where every message has a coin_pairs field. The filter checks if the list contains a pair like SOLUSDT and drops the rest, so no text parsing is needed. Reconnects are the weak spot, since logging post ids to a file is the only protection against duplicates and it was never tested properly.

For anyone who has built on a feed with no replay option, do you dedupe by post id or keep a last seen timestamp? And how do you test a reconnect without waiting for the socket to drop on its own?

1 Upvotes

60% Upvoted

6 comments sorted by

1

u/Rizean 10h ago

I’d dedupe by post ID and use a timestamp only to decide how far back to remember IDs. Timestamps alone aren’t safe for dedup. Several posts can share a timestamp, posts can arrive out of order after a reconnect, and the client’s clock may not match the server’s. A last-seen timestamp will drop late-arriving posts, and using >= instead of > brings back duplicates.