Fix accidental workflow triggering #1136

Closed
opened 2026-04-05 16:25:34 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @xuebingli on 3/14/2024

Fix Accidental Workflow Triggering

Diagnosis

@koroglumert reported multiple workflow triggers with a single state change. Upon investigation, there are at least two code paths independently triggering workflows for the same change to currentScheduledMaintenanceStateId.

  1. changeScheduledMaintenanceState in ScheduledMaintenanceService.ts 64e0d3e7fa/CommonServer/Services/ScheduledMaintenanceService.ts (L424-L428)

  2. onCreateSuccess in ScheduledMaintenanceStateTimelineService.ts 64e0d3e7fa/CommonServer/Services/ScheduledMaintenanceStateTimelineService.ts (L128-L135)

In addition, the same error is reported to also happen to the "On Update Incident" trigger. Therefore, there may be quite a few similar bugs with other resources in the code base.

The Fix

The easy fix is to remove one of the aforementioned code paths. However, this only addresses the issue for ScheduledMaintenance and fails to address other existing issues let alone guarding against similar bugs in the future.

Instead, this PR adds a check before workflow triggers, ensuring that multiple identical updates (e.g. updating currentScheduledMaintenanceStateId twice to the same value) only trigger workflow once. The goal is to fix a category of bugs, both existing one and ones that may pop up in the future.

Pull Request Checklist:

  • Please make sure all jobs pass before requesting a review.
  • Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if such).
  • Have you lint your code locally before submission?
  • Did you write tests where appropriate?

Closes #1113

Screenshots (if appropriate):

I reproduced the scenario in #1113 with Listen on set to { "currentScheduledMaintenanceStateId": true }.

The screenshot below shows that only two workflow triggers during the lifecycle of a scheduled maintenance. One for transitioning from Scheduled to Ongoing, and the other for Ongoing to Ended. No more unexpected triggers.
Screenshot 2024-03-14 at 4 46 08 PM

The details of the two triggers are as follows.
Screenshot 2024-03-14 at 4 46 41 PM
Screenshot 2024-03-14 at 4 46 46 PM

*Originally created by @xuebingli on 3/14/2024* ## Fix Accidental Workflow Triggering ### Diagnosis @koroglumert reported multiple workflow triggers with a single state change. Upon investigation, there are at least two code paths independently triggering workflows for the same change to `currentScheduledMaintenanceStateId`. 1. `changeScheduledMaintenanceState` in ScheduledMaintenanceService.ts https://github.com/OneUptime/oneuptime/blob/64e0d3e7fa803a6e961bbbcc4ed97ac4ec61fa8c/CommonServer/Services/ScheduledMaintenanceService.ts#L424-L428 1. `onCreateSuccess` in ScheduledMaintenanceStateTimelineService.ts https://github.com/OneUptime/oneuptime/blob/64e0d3e7fa803a6e961bbbcc4ed97ac4ec61fa8c/CommonServer/Services/ScheduledMaintenanceStateTimelineService.ts#L128-L135 In addition, the same error is reported to also happen to the "On Update Incident" trigger. Therefore, there may be quite a few similar bugs with other resources in the code base. ### The Fix The easy fix is to remove one of the aforementioned code paths. However, this only addresses the issue for `ScheduledMaintenance` and fails to address other existing issues let alone guarding against similar bugs in the future. Instead, this PR adds a check before workflow triggers, ensuring that multiple identical updates (e.g. updating `currentScheduledMaintenanceStateId` twice to the same value) only trigger workflow once. The goal is to fix a *category* of bugs, both existing one and ones that may pop up in the future. ### Pull Request Checklist: - [x] Please make sure all jobs pass before requesting a review. - [x] Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such). - [x] Have you lint your code locally before submission? - [x] Did you write tests where appropriate? ### Related Issue Closes #1113 ### Screenshots (if appropriate): I reproduced the scenario in #1113 with `Listen on` set to `{ "currentScheduledMaintenanceStateId": true }`. The screenshot below shows that only two workflow triggers during the lifecycle of a scheduled maintenance. One for transitioning from `Scheduled` to `Ongoing`, and the other for `Ongoing` to `Ended`. No more unexpected triggers. <img width="1506" alt="Screenshot 2024-03-14 at 4 46 08 PM" src="https://github.com/OneUptime/oneuptime/assets/1525352/298ae66c-f230-4510-85e0-442af574d51f"> The details of the two triggers are as follows. <img width="1141" alt="Screenshot 2024-03-14 at 4 46 41 PM" src="https://github.com/OneUptime/oneuptime/assets/1525352/f3468783-7a3c-4953-bea2-1fa2f88b8778"> <img width="1141" alt="Screenshot 2024-03-14 at 4 46 46 PM" src="https://github.com/OneUptime/oneuptime/assets/1525352/4ec873fb-5185-4546-b62c-9cfc0f7887ec">
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#1136