Closed lukeheath closed 2 months ago
@getvictor Since you're working on the calendar cron env var ticket I'm assigning this straight to you. I'll be giving any calendar bugs a P2
because there is an associated urgency for this feature to demo well in the near future.
This bug was hard to notice with the 30 minute cron, but I hardcoded it back to 30 seconds last night on dogfood and it's a bit easier to chaos engineer the calendar feature that way.
cc @sharon-fdm
@getvictor informed me this is intended behavior. We wait 24 hours after the event before re-booking for the same policy to give the user (and IT if necessary) time to complete necessary processes.
In the cloud city's heart, Meetings rebooked, errors thwart, A fresh start, smart art.
Fleet version: <!-- Copy this from the "My account" page in the Fleet UI, or run
fleetctl --version
-->4.50.2
Web browser and operating system: Chrome
💥 Actual behavior
I have a policy that will always fail my host.
The calendar events automation is enabled for this policy.
When I first fail the policy, the scheduled maintenance event is created as expected. If I delete it or move it to the past, it rescheduled as expected. But, if I let the scheduled maintenance event start, it will never re-book scheduled maintenance for my host for this failing policy. The only way to trigger it is to update the policy, fetch my host so it passing, then update the policy again and refetch my host so it is failing. As soon as I do that, it recognizes the newly failed policy and creates the event. But it does not recognize existing failed policies that have already had scheduled events.
The expected behavior is that if scheduled maintenance fails to resolve a failing policy, another scheduled maintenance event is created at the first check after the first event is complete.
🧑💻 Steps to reproduce
🕯️ More info (optional)
N/A