fix: [AAP-24814] prevent request enqueuing when parent deleted

[jshimkus-rh]

No description provided.

[jshimkus-rh]

Tests to come.

[Alex-Izquierdo]

Hi @jshimkus-rh What I noticed is that once the activation is deleted I saw in every loop of the monitor the message:

May 30 14:10:44 ip-10-0-2-14.ec2.internal automation-eda-controller-worker-1[4947]: 2024-05-30 14:10:44,224 aap_eda.tasks.orchestrator INFO     Dispatching request auto_start for activation 77
May 30 14:10:44 ip-10-0-2-14.ec2.internal automation-eda-controller-worker-1[4947]: 2024-05-30 14:10:44,225 aap_eda.tasks.orchestrator WARNING  activation 77 no longer exists, request auto_start can not be dispatched.

It seems that the problem is after run _queue_auto_start

I think there is a bug in this PR, because in _queue_auto_start we couldn't add the request if the activation was deleted, but later we removed that constraint (the activation is a foreign key, but the process_parent_id don't), so we put in the queue the request even if the activation doesn't exist.

I'm afraid that just cancelling the job could not be enough. What do you think about handling the issue in _queue_auto_start and check for the existence of the process_parent before add it to the queue?

[jshimkus-rh]

It seems that the problem is after run _queue_auto_start

Right. And cancelling that before it gets a chance to run prevents the problem.
Certainly there's no need to let a job run just to have it fail.

Ultimately, as pointed out in that PR, it's the requests_queue push that's the culprit.