How to decide resubscribe interval for client observers

[klasrpersson]

Hello,
I have an application that uses websockets to communicate to clients and the communication between the silo and the websocket server is using client side observers. The documentation says that we need to resubscribe periodically and it says that it is due to the fact that ObserverManager marks observers as stale after a while if they are idle.

If i store the observer identities in persisted state in the grain so that they can be recovered if the silo restarts, is the "stale timeout" the only thing that affects my resubscribe interval?
Or will the stored observer identities be useless after silo restart so that i need to wait for a resubscribe before i can push out messages to the client? Meaning a downtime of up to the length of the interval.

[ReubenBond]

Hi @klasrpersson the validity of an observer reference is tied to the lifecycle of the observer (eg client) itself, and not the silo. They can survive silo restarts but not client restarts.

The resubscribe interval is used as a cleanup mechanism for observers which either point to defunct clients or have been disposed by the client (eg, the reference has gone out of scope and has been garbage-collected). A short interval means you have network chattiness & overhead. A large interval means you hold onto defunct references for a longer period after they become invalid, possibly resulting in error or warning logs.

The need for a cleanup interval arises from the observer methods being void and therefore one-way calls - there is no signal back to the grain that the observer reference is dangling. If you make the observer methods return a task, you can await the call and decide to remove the reference if it fails.