There are a few examples when relying on existing notification triggers won't be enough the way they are configured. For example a sync is considered successful if the app is also healthy. But there are cases like Keda ScaledObject suspended, which would cause the app state to be suspended.
Motivation
We have an automation that relies on signals about sync success/failure arriving to lambda (customly configured). But sometimes nothing would arrive due to edge cases.
Proposal
Maybe treat sync success + app suspended as sufficient to have sync succeeded trigger. Need to be careful, when suspended is a temporary state.
Another case is sync successful, but app is degraded due to some deleted resources that were not pruned. We ideally want to distinguish that with app unhealthy for other reasons and maybe send sync failed.
Summary
There are a few examples when relying on existing notification triggers won't be enough the way they are configured. For example a sync is considered successful if the app is also healthy. But there are cases like Keda ScaledObject suspended, which would cause the app state to be suspended.
Motivation
We have an automation that relies on signals about sync success/failure arriving to lambda (customly configured). But sometimes nothing would arrive due to edge cases.
Proposal
Maybe treat sync success + app suspended as sufficient to have sync succeeded trigger. Need to be careful, when suspended is a temporary state. Another case is sync successful, but app is degraded due to some deleted resources that were not pruned. We ideally want to distinguish that with app unhealthy for other reasons and maybe send sync failed.