Drift detection runs are added to the queue just on the cron schedule, in a low prio state.
When for such a scheduled stack, a tracked run is already in the queue, or added to it, the drift detection run is not removed.
Goven the drift detection run is scheduled with a commit sha, that is not up to date any more when new tracked runs are added, this wil cause some flipping issues in applying changes / perceived drifts.
Combined with drift detction only after x amount of time, this allows for more frequent drift detction schedules while at the same time removing a lot of unneeded runs. Esp in large volume stacks with high volume of changes…