Minion's should never change a job's JID if it's already assigned. It was discovered that the minion process is giving new queued jobs new JIDs. I assume this bug was introduced by trying to support something related to salt-call where jobs do not have JIDs assigned by the master.
Here is some diagnosis: The state-queue refactor in a21bc25 (v3006.21) conflated "the queued payload needs a guaranteed-unique JID" with "the queued payload needs its own JID", and replaced the master's __pub_jid with a freshly-minted one. A drain-side rewrite masked the symptom until e002fbc (v3006.24) reverted the queue filename to also use the new JID, removing the mask.
Version: 3006.24
Minion's should never change a job's JID if it's already assigned. It was discovered that the minion process is giving new queued jobs new JIDs. I assume this bug was introduced by trying to support something related to salt-call where jobs do not have JIDs assigned by the master.
Here is some diagnosis: The state-queue refactor in a21bc25 (v3006.21) conflated "the queued payload needs a guaranteed-unique JID" with "the queued payload needs its own JID", and replaced the master's __pub_jid with a freshly-minted one. A drain-side rewrite masked the symptom until e002fbc (v3006.24) reverted the queue filename to also use the new JID, removing the mask.
Version: 3006.24