Variable Machine Scoping not being respected when running pre-deployment validation with Tenants

[Clare-Octopus]

Severity

Blocking customers from deploying to tenants in some senarios. Workaround is to deploy directly to machines but sometimes not feasable.

Version

2025.3.4509

Latest Version

I could reproduce the problem in the latest build

What happened?

If I use a Library Variable Set with values scoped to machines and then try to deploy to tenants, the deployment may not be able to be created in some situations (depending on the variable type - aka Accounts Variables) due to the machine scoping for the variables not being respected (therefore some machines may not have access to the resources - aka Accounts - associated with the variables).

An example of this is shown below:

Say I have a Library Variable Set with some accounts in scoped -

Clare AWS is scoped to a target (MainComputeOperationsPollingTarget) associated with a tenant called Tenant A ClareMainAzureAccount is scoped to target (OctoDCPollingTarget) associated with a tenant called TenantVarSet

I then have Tenant A and TenantVarSet connected to a project called TestVarSetProject, which has a simple Run a Script step in it. That deploys to both those deployment targets associated with those tenants and just Write-Hosts the Accounts variable from above in the script.

So when I go to deploy a release from that project to Tenant A, it does throw an error for the variable its not even scoped to (its scoped to the Clare AWS account), so it does look like we are searching both variables here. It also does the same thing if I deploy to TenantVarSet but it throws an error on the other variable:

Reproduction

1. Create 2 tenants, and associate them with environments.
2. Ensure you have two deployment targets and associate them with the individual tenants we created in Step 1 (each deployment target only has one tenant associated with it).
3. Create 2 Accounts in Octopus, ensure you associate them with each individual tenant we created in Step 1 (each account only has one tenant associated with it).
4. Create a variable set and have an accounts variable (call it 'Accounts' that has 2 values (use the accounts we created in Step 3). One value scoped to one deployment target we used in Step 2 and the other with the other target (aka one with one tenant and the other account with the other tenant).
5. Create a tenanted project and add the variable set we created in Step 4. Have a simple Run a Script step and have it run this script 'Write-Host "$Accounts"' (with the account variable we created in Step 4 being referenced).
6. Attach both tenants we created in Step 1 to the project with the relevent environments.
7. Try to deploy the project to either tenant and notice you get an error that the tenant doesnt have access to one of the accounts we created even though that account is scoped to the other tenants deployment target.
8. Try and deploy that project to the deployment target (aka untenanted) and see it deploy and print out the correct account the variable is scoped to.

Error and Stacktrace

N/A

More Information

Initial ticket (internal) - https://octopus.zendesk.com/agent/tickets/242164 RnD (Internal) - https://octopusdeploy.slack.com/archives/CNHBHV2BX/p1751642479555959 Reproduction (Internal) - https://octopus-operations.octopus.app/app#/Spaces-422/projects/testvarsetproject/deployments/releases/0.0.21/deployments/create?environmentIds=Environments-2522

Workaround

If you deploy directly to each deployment target, the variable scoping will be respected, so that is one way to work around this bug. However, sometimes that is not feasible (aka if you are deploying to 20 tenants, all having six machines per tenant).