@realmain has a group that's configured to show any events occurring over the next 60 days, but is restricted to at most 5 events. His group's calendar typically has more than 5 events during that window, so that tends to be the limit on events' view. The logic to check for removed events only checks to see if an event in the previous iteration's view is present in the current view, so for example if at 8 a.m. the bot generates a view for a calendar with:
Alpha Event
today at 12 pm
Bravo Event
tomorrow at 12 pm
Charlie Event
in 2 days at 12 pm
Delta Event
in 3 days at 12 pm
Echo Event
in 4 days at 12 pm
Foxtrot Event
in 60 days at 12 pm
it'll show Alpha, Bravo, Charlie, Delta, and Echo, leaving Foxtrot off because, even though it's within 60 days, it's the 6ᵗʰ event. Then if at 9 a.m. the bot generates a new view for:
Alpha Event
today at 12 pm
Zulu Event
today at 6 pm
Bravo Event
tomorrow at 12 pm
Charlie Event
in 2 days at 12 pm
Delta Event
in 3 days at 12 pm
Echo Event
in 4 days at 12 pm
Foxtrot Event
in 60 days at 12 pm
the view will only include Alpha, Zulu, Bravo, Charlie, and Delta, so it will appear as if Echo had been removed from the calendar, generating an update message:
Updated:
Zulu Event
• New event!
Echo Event
• Removed.
One possibility would be to query for the event's id to verify it has actually been removed from the calendar versus just dropping out of the view. It might even make sense to force the event back into the view (so the updated daily announcement will include 6 events instead of the 5 it's configured to list), if only to handle the situation where an event is removed from a view because its start date has changed (which probably should be reported). It might make the most sense to do the query, check if anything has actually changed, and force it back into the view if so, otherwise (if nothing has changed—suggesting it has fallen out of the view because of a config change or the addition of a new event) allow it to silently drop out of the announcement.
Another possibility would be to simply ignore removals at the end of the list, but that would lead to incorrectly ignoring events that actually have been deleted if they just happen to be at the end of a view.
However this is resolved, we should keep in mind the related situation of events coming into/leaving a view because of a config change. For example, if @realmain reconfigured his group to show the next 10 events, the 10 a.m. update would currently report:
Updated:
Echo Event
• New event!
Foxtrot Event
• New event!
and similarly if he dropped it to 3:
Updated:
Charlie Event
• Removed.
Delta Event
• Removed.
We can probably handle the latter case however we handle the addition of new events pushing existing events out, but the former case would need us to be able to query the calendar as of when the previous announcement was made (to determine that Echo and Foxtrot did actually already exist on the calendar then). There might be something clever we can do here (other than serializing and storing a snapshot of the entire calendar), but it might be that we just do the exists-but-is-now-outside-of-the-view check against the live calendar to properly handle non-removals and live with spurious "New event!" updates.
@realmain has a group that's configured to show any events occurring over the next 60 days, but is restricted to at most 5 events. His group's calendar typically has more than 5 events during that window, so that tends to be the limit on
events' view. The logic to check for removed events only checks to see if an event in the previous iteration's view is present in the current view, so for example if at 8 a.m. the bot generates a view for a calendar with:it'll show Alpha, Bravo, Charlie, Delta, and Echo, leaving Foxtrot off because, even though it's within 60 days, it's the 6ᵗʰ event. Then if at 9 a.m. the bot generates a new view for:
the view will only include Alpha, Zulu, Bravo, Charlie, and Delta, so it will appear as if Echo had been removed from the calendar, generating an update message:
One possibility would be to query for the event's id to verify it has actually been removed from the calendar versus just dropping out of the view. It might even make sense to force the event back into the view (so the updated daily announcement will include 6 events instead of the 5 it's configured to list), if only to handle the situation where an event is removed from a view because its start date has changed (which probably should be reported). It might make the most sense to do the query, check if anything has actually changed, and force it back into the view if so, otherwise (if nothing has changed—suggesting it has fallen out of the view because of a config change or the addition of a new event) allow it to silently drop out of the announcement.
Another possibility would be to simply ignore removals at the end of the list, but that would lead to incorrectly ignoring events that actually have been deleted if they just happen to be at the end of a view.
However this is resolved, we should keep in mind the related situation of events coming into/leaving a view because of a config change. For example, if @realmain reconfigured his group to show the next 10 events, the 10 a.m. update would currently report:
and similarly if he dropped it to 3:
We can probably handle the latter case however we handle the addition of new events pushing existing events out, but the former case would need us to be able to query the calendar as of when the previous announcement was made (to determine that Echo and Foxtrot did actually already exist on the calendar then). There might be something clever we can do here (other than serializing and storing a snapshot of the entire calendar), but it might be that we just do the exists-but-is-now-outside-of-the-view check against the live calendar to properly handle non-removals and live with spurious "New event!" updates.