-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add divergence summary notification on a given interval #85
Conversation
ab1ff65
to
31b3152
Compare
57d363c
to
646861f
Compare
a7414ba
to
aebb8ab
Compare
a855dd0
to
e07ce1d
Compare
@@ -648,6 +654,10 @@ pub async fn process_comparison_results( | |||
} | |||
} | |||
|
|||
if !notification_summary.is_empty() { |
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.
hmmm there's a difference in the idea of interval
versus a ratelimit
. I can see how the current changes can easily turn into a daily report notification (can be a periodic_report
enum)
for the ratelimit
purpose of this PR (which I think you reframed into interval
and became more of a daily report idea), I think the live notifications should be throttled into an aggregation, like your notification_summary
+ a dedup + tracked by the notifier. Then here you check if the summary is empty and if it should be ratelimited conditioning on the mode, before sending the summary.
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.
I don't understand this comment
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.
okay, do you have a question about it? could you tell me what do you not understand so I can explain further
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.
I think we agree on the periodic_report
option flow & implementation right? So it's just the live
flow that you have concerns about here? How/why does a ratelimit fit into the live
flow? If users want to limit their notifications they can use periodic_report
, that's why we're adding it (I think).
I agree about the dedup but why does the summary have to be tracked by notifier
? Isn't it properly constructed now during each comparison event?
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.
Ok, I think the confusion here is caused by what should the aggregated notifications show to the users when they have set a notification interval.
- If users use
live
, the worst case is they may get 1 notification every comparison interval ~300s if there's any result worth notifying on the result type - If users use
periodic_report
, they will get a summary generated based on the stored states by their configured interval. The report informs the state of the system but doesn't indicate what has changes from before and possibly be the same as the previous interval. This is good as it is consistent and predictable. - My point with this comment is we are missing a mode where the users will get notified by their configured interval (like
periodic_report
) and only if there's something worth notifying (similar to thelive
check). In order for the radio to know if it should notify across comparison intervals, the notifier has to know either what was the states in the previous state or it tracks worthy notifications along the way. Though this mode of notification doesn't have to live here withlive
and could live with thenotification_interval
matched onnotification_mode
let me know if this is more clear, or if you want to leave this to another PR
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.
definitely more clear, thank you! 💯
0a163bf
to
f40601b
Compare
dc53683
to
ba5d573
Compare
@@ -14,16 +14,30 @@ pub struct Notifier { | |||
discord_webhook: Option<String>, | |||
telegram_token: Option<String>, | |||
telegram_chat_id: Option<i64>, | |||
pub notification_mode: NotificationMode, | |||
pub notification_interval: u64, | |||
pub notifications: Vec<String>, |
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.
if we update notifications
to be an Arc<Mutex<Vec<String>>>
then do we still need notifier to be in an Arc<Mutex<>>
?
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.
Sadly nope, the whole notifier
gets passed around between threads, but even if it wasn't there's trait issues if we try that, the Serialize
and PartialEq
traits on Notifier
complain about an Arc<Mutex<>> field
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.
Hmmmmm okay, then what if we ask persisted state to track the notifications instead of for notifier to track it? this way we get to keep notifier simple and notifications can be preserved across startups as well. This can be something to discuss later though might be relatively easy to refactor now
ba5d573
to
cdb399c
Compare
cdb399c
to
99d7b85
Compare
f218d96
to
93bbb06
Compare
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.
notifications system on steroids ❗
93bbb06
to
aa293a7
Compare
NOTIFICATION_MODE
config var, supportslive
,periodic-report
andperiodic-update
options, live being the current functionality, periodic-report sending a summary of all divergences on a given interval and periodic-update accumulates the notifications that live would send, but sends them at a given interval (both periodic options can be configured with the newNOTIFICATION_INTERVAL
, default is 24 every hours)notification_interval
) in tokio::select to facilitate the new daily action ifNOTIFICATION_MODE=periodic_report
NOTIFICATION_MODE