-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for disabling overflow-warning logs in broadcast receivers #329
Conversation
This is required in cases where users are only interested in the latest value, for example. Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>
Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not super excited about the extra complexity, and I was thinking it would be great to manage this via the config system, but even if we have a separate logger for these warnings so it can be disabled more easily, this doesn't allow us to show warnings for some receivers but not others, so I guess it doesn't cut it.
My main concern is I guess we are adding this only to cope with the fact that we can't unsubscribe/remove receivers, right? Or am I missing any other use case for this? It seems like having a channel overflowing is not good unless you don´t really care about receiving data from it.
It is for cases where we want just the latest value, but also want a trigger, want to put it in a |
OK, and in that case it will be combined with |
How about a private method |
Unless having this is urgent, I'd rather spend some time thinking about a final solution than introducing a hack. And if we are going for the hack, I would be more inclined to have |
Moving the discussion to: To avoid polluting the PR too much. |
No description provided.