Closed yhabteab closed 4 months ago
- As it is a new incident, it gets
.Sync
ed https://github.com/Icinga/icinga-notifications/blob/7b6ea92672841ad3ba28927d8c00e9ae68443ce0/internal/incident/incidents.go#L248
If it is synced here, there should be no problems. The real problem, however, is that if there is an existing incident, that fake event will make its way to the fellowing scopes multiple times. https://github.com/Icinga/icinga-notifications/blob/59861289ce06d4b264f1b42e941d3b520cba332a/internal/incident/incident.go#L147 https://github.com/Icinga/icinga-notifications/blob/59861289ce06d4b264f1b42e941d3b520cba332a/internal/incident/incident.go#L163-L164
When the incident finally notices that this ack set event is superfluous here ...
https://github.com/Icinga/icinga-notifications/blob/59861289ce06d4b264f1b42e941d3b520cba332a/internal/incident/incident.go#L199-L200
It will simply return without committing the transaction, leaving the now dangling ev.ID
set above.
Event#Sync()
synchronises an event row with the database only if its ID is set to no other value than0
. Therefore, we must reset the event ID for the acknowledgement set event generated in the catch-up phase before resending it.