Service history of checks, applied directly to masters, is mixed up between each other

[K0nne]

Describe the bug

The service history of checks, which are applied directly to both ha-masters, is reproducable mixed up.
So far I observed this behaviour only with checks between both masters.

To Reproduce

1. have an ha-setup
2. apply "random" to both masters
3. the history of both checks should mix up

Expected behavior

No mixup of service histories should happen.

Screenshots

I observed this the first time during an outage when I looked at another check, which was applied directly to both masters.
In this case, the complete history of this check on master02 is stuffed into the history of the same check at master01:

yesterday I reproduced it with "random".
here are pieces of the check on master01 mixed into the history of the check on master02:

(on a sidenote: the initial state change is counted as 2 / 3)

Your Environment

Include as many relevant details about the environment you experienced the problem in

• Version used (icinga2 --version): 2.15.2
• Operating System and version: RHEL 8.10
• Enabled features (icinga2 feature list):

• Icinga Web 2 version and modules (System - About): 2.12.5
• Config validation (icinga2 daemon -C):

Additional context

• icingadb 1.5.1
• redis 8.2.3

[00Manas-Singh00]

@K0nne, the IDs were based on object name, which is too weak in HA when you have same-named checks on different masters, so history rows could get mixed.

I fixed it by switching state history ID generation to use the stable Icinga DB object identifier (the same identity we already use for service_id/host_id relations),