Skip to content

Commit 6f3c867

Browse files
Merge pull request #262371 from ApnaLakshay/pre-post-important-pointers-added
Pre post important pointers added
2 parents cb340f5 + 96ad7aa commit 6f3c867

File tree

2 files changed

+23
-1
lines changed

2 files changed

+23
-1
lines changed

articles/update-manager/manage-pre-post-events.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ To self-register your subscription for public preview in Azure portal:
2727

2828
## Timeline of schedules for pre and post events
2929

30-
We recommend you to go through the following table to understand the timeline of the schedule for pre and post events.
30+
**We recommend you to go through the following table to understand the timeline of the schedule for pre and post events.**
3131

3232
For example, if a maintenance schedule is set to start at **3:00 PM**, with the maintenance window of 3 hours and 55 minutes for **Guest** maintenance scope, following are the details:
3333

@@ -40,6 +40,8 @@ For example, if a maintenance schedule is set to start at **3:00 PM**, with the
4040
|6:55 PM | The post event gets triggered after the defined maintenance window completes. If you have defined a shorter maintenance window of 2 hrs, the post maintenance event will trigger after 2 hours and if the maintenance schedule is completed before the stipulated time of 2 hours that is, in 1 hr 50 mins, the post event will start. </br></br> In this example, if the maintenance window is set to the maximum, then by 6:55 PM the patch installation process is complete and if you have a shorter maintenance window, the patch installation process is completed by 5:00 PM. |
4141
|7:15 PM| After the patch installation, the post event runs for 20 mins. </br>In this example, the post event is initiated at 6:55 PM and completed by 7:15 PM and if you have a shorter maintenance window, the post event is triggered at 5:00 PM and completed by 5:20 PM. |
4242

43+
>[!IMPORTANT]
44+
> Make sure to have atleast 40 minutes before the scheduled maintenance run time (3:00 PM in above example) otherwise it might lead to auto-cancellation of that particular scheduled run.
4345
4446
## Configure pre and post events on existing schedule
4547

@@ -109,6 +111,9 @@ There are two types of cancelations:
109111

110112
> [!NOTE]
111113
> If the cancelation is done by the system, the upcoming scheduled patching job will be canceled due to the failure of running the pre events by the sytem.
114+
115+
>[!IMPORTANT]
116+
> If the scheduled maintenance job is cancelled by the user using cancelation API or by the system due to any internal failure, post event if subscribed, will be sent to the endpoint configured by the user.
112117
113118
### View the cancelation status
114119

articles/update-manager/pre-post-events-common-scenarios.md

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -169,6 +169,23 @@ You can view the status of the maintenance job from the ARG query mentioned abov
169169

170170
:::image type="content" source="./media/pre-post-events-common-scenarios/view-job-status.png" alt-text="Screenshot that shows how to insert the resource group, maintenance configuration." lightbox="./media/pre-post-events-common-scenarios/view-job-status.png":::
171171

172+
173+
## Why the scheduled run was cancelled by the system?
174+
175+
The system cancels the scheduled run if one or more of the following conditions are not met:
176+
177+
1. If the maintenance configuration has at least one pre event subscribed and the schedule time is changed within the 40-minute window before the scheduled start time.
178+
2. If the pre-event was created within the 40-minute window before the scheduled start time.
179+
180+
181+
## Why the post event was not sent by the system?
182+
183+
If the user modifies the schedule run time after the pre-event has been triggered, the post event will not be sent because the scheduled time has been replaced with a new one.
184+
185+
> [!NOTE]
186+
> Azure Event Grid adheres to an at-least-once delivery paradigm. This implies that, in exceptional circumstances, there is a chance of the event handler being invoked more than once for a given event. Customers are advised to ensure that their event handler actions are idempotent. In other words, if the event handler is executed multiple times, it should not have any adverse effects. Implementing idempotency ensures the robustness of your application in the face of potential duplicate event invocations.
187+
188+
172189
---
173190

174191
## Next steps

0 commit comments

Comments
 (0)