Task Queueing for Different Targets

[ShannonN]

We recently ran into a particularly confusing situation that we’re hoping you can help with.

Project A was deploying via a worker in a pool (let’s call the worker CICD01) and it was held up by a different server task:

Here’s the confusing part; clicking the server task takes us to Project B which is deploying to a different target server (lets call the target CICD02). We’ve checked the host settings for both the worker and the target and they’re different. We also looked up the DNS records for the hosts and they resolved to different IPs. The only thing that’s common is the fingerprint (occasionally our infrastructure guys clone systems without refreshing them). Could this potentially be causing this issue? I would think that internally Octopus identified targets (workers or targets) based on their machine or worker ID and not the thumbprint.

Any thoughts would be helpful. Thanks.

[brent_kinney]

Hi @ShannonN,

Thanks for reaching out on our community forum. I’m sorry that you’ve run into this issue, but I can help get things sorted. The shared thumbprint is most likely the issue here. Octopus differentiates workers and targets using the machine thumbprint, so if a VM was cloned and the same thumbprint was used, it would cause issues like this.

I hope that helps clarify things. Let us know if you have any other questions.

Best,
Brent

[ShannonN]

Thank you for confirming Brent. Another story for the backlog!