I noticed this while checking the durable background-job reattach path.
If a matching running job exists, QM calls readProcess() to check whether it is still alive. Any error from that check currently deletes the registry row and starts the command again.
A temporary backend error can therefore leave the original process running, start a second copy, and lose the durable record of the first one.
I reproduced this locally on 0f0e0ad with the public broker factory. The second start returned a new process ID, while the registry retained only the replacement.
Could the reattach path only delete and restart after a confirmed “no such process” error? Other errors could keep the row intact and surface the failure.
Happy to help verify a fix.
I noticed this while checking the durable background-job reattach path.
If a matching running job exists, QM calls
readProcess()to check whether it is still alive. Any error from that check currently deletes the registry row and starts the command again.A temporary backend error can therefore leave the original process running, start a second copy, and lose the durable record of the first one.
I reproduced this locally on
0f0e0adwith the public broker factory. The second start returned a new process ID, while the registry retained only the replacement.Could the reattach path only delete and restart after a confirmed “no such process” error? Other errors could keep the row intact and surface the failure.
Happy to help verify a fix.