Skip to content

🐛 Make FindLatestMachine independent of list order - #419

Open
lbarrosby wants to merge 1 commit into
ionos-cloud:mainfrom
lbarrosby:fix-find-latest-machine-order
Open

lbarrosby wants to merge 1 commit into
ionos-cloud:mainfrom
lbarrosby:fix-find-latest-machine-order

Conversation

@lbarrosby

Copy link
Copy Markdown

What is the purpose of this pull request/Why do we need it?

Machine.FindLatestMachine returns a different result for the same set of machines depending on the order in which the list comes back. swapNICInFailoverGroup relies on it to pick the machine that takes over the failover IP when a machine in the failover group is deleted.

Issue #, if available:

None.

Description of changes:

The loop started with latestMachine := machines[0] and only skipped the receiver inside the loop. If the receiver is the first listed machine and also the newest one, no other machine passes the !Before(latest) check, latestMachine stays the receiver and the function returns nil, although other machines exist. With the same machines listed in another order (receiver last), it returns the newest of the others.

Example with three control plane machines where the one being deleted is the newest:

  • receiver cp-test-1: returns nil
  • receiver cp-test-3: returns cp-test-2

When it returns nil, swapNICInFailoverGroup does nothing, so the failover group keeps the NIC of the machine that is being deleted, for example when a MachineDeployment with the Newest delete policy scales down.

The fix skips the receiver up front and returns the newest of the remaining machines, or nil when there is none.

Special notes for your reviewer:

TestFindLatestMachineMachineIsReceiver expected nil for exactly this case (receiver cp-test-1 is newer than cp-test-2). I changed it to expect cp-test-2, since the doc comment says only machines other than the receiver are considered and nil is returned only when the receiver is the only one. If returning nil there was intended, let me know and I will rework this.

Added TestFindLatestMachineReceiverIsNewest, which runs the same scenario with the receiver in each list position. On main the cp-test-1 case fails and the other two pass; with the fix all pass. go test ./scope/ ./internal/service/cloud/ passes locally.

AI disclosure: written with the help of Claude Code, reviewed and tested by me.

Checklist:

  • Documentation updated
  • Unit Tests added
  • E2E Tests added
  • Includes emojis

FindLatestMachine started with the first listed machine and skipped the
receiver only inside the loop. When the receiver was both first in the
list and the newest machine, no other machine could replace it and the
function returned nil, although other machines existed. With the same
machines in a different order it returned the newest other machine.

swapNICInFailoverGroup uses this result to move the failover IP to
another NIC. A nil result leaves the failover group pointing at the NIC
of the machine that is being deleted.

Skip the receiver up front and return the newest of the remaining
machines, or nil if there is none.

Signed-off-by: Lucas Barros <lucasbarros.kam@gmail.com>
@sonarqubecloud

sonarqubecloud Bot commented Nov 6, 2026

Copy link
Copy Markdown

This branch is waiting to be deployed

1 waiting deployment
e2e — 0685480c Waiting Nov 6, 2026 by lbarrosby via e2e #698
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant