You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The SDK server is not able to handle closed streams. Watching for game server updates leads to frequent errors in the sidecar.
When the connection is closed anyway, the sidecar log prints an error at least on every resync (default 30s?) which becomes quiet noisy for a non-error situation (from the game server perspective).
Describe the solution you'd like
In Go it's a best practice to clean up resources that you no longer need. Keeping a GRPC stream open forever for no reason is not necessary.
The suggested solution removes the stream from the connected stream slice, if the context is done, usually by cancellation.
Describe alternatives you've considered
The alternative approach was to implement something on the client to keep reading from the stream, but discarding any received message. It adds unnecessary complexity and just circumvents bad behavior at the wrong place.
Another possibility would be to drop the error messages when logs are collected (e.g. by Loki), but that's just not an option.
Additional context
I noticed reports/discussions around "unwatch", e.g. #2939 but I didn't see a valid reason to not implement it.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The SDK server is not able to handle closed streams. Watching for game server updates leads to frequent errors in the sidecar.
When the connection is closed anyway, the sidecar log prints an error at least on every resync (default 30s?) which becomes quiet noisy for a non-error situation (from the game server perspective).
Describe the solution you'd like
In Go it's a best practice to clean up resources that you no longer need. Keeping a GRPC stream open forever for no reason is not necessary.
The suggested solution removes the stream from the connected stream slice, if the context is done, usually by cancellation.
Describe alternatives you've considered
The alternative approach was to implement something on the client to keep reading from the stream, but discarding any received message. It adds unnecessary complexity and just circumvents bad behavior at the wrong place.
Another possibility would be to drop the error messages when logs are collected (e.g. by Loki), but that's just not an option.
Additional context
I noticed reports/discussions around "unwatch", e.g. #2939 but I didn't see a valid reason to not implement it.
The text was updated successfully, but these errors were encountered: