When multiple sessions exist for the same probe_id, the check volume should be distributed between them.
When building the list of checks to assign to a probe, we first get the list of connected sessions. it is expected that this list of sessions will be consistently orderd. However the query to fetch the sessions orders them by 'updated' timestamp. this leads to a race condition where the order of the sessions changes each time a session heartbeat is received. eg.
probeA -> sends heartbeat and 'updated' is set to 1
probeA starts refresh, active sessions are returned as [probeA, probeB]
probeB -> sends heartbeat and 'updated' is set to 10
probeB starts refresh, active sessions are returned as [probeB, probeA]
To ensure consistency, the probe_sessions should be orderd by their "id".
When multiple sessions exist for the same probe_id, the check volume should be distributed between them. When building the list of checks to assign to a probe, we first get the list of connected sessions. it is expected that this list of sessions will be consistently orderd. However the query to fetch the sessions orders them by 'updated' timestamp. this leads to a race condition where the order of the sessions changes each time a session heartbeat is received. eg.
probeA -> sends heartbeat and 'updated' is set to 1 probeA starts refresh, active sessions are returned as [probeA, probeB] probeB -> sends heartbeat and 'updated' is set to 10 probeB starts refresh, active sessions are returned as [probeB, probeA]
To ensure consistency, the probe_sessions should be orderd by their "id".