nextAvailableVNet fails when using multiple blocks and smallest_cidr option true if no IP range is available in first block

Describe the bug
nextAvailableVNet fails with an internal server error (500) when using multiple blocks and smallest_cidr option true if no IP range is available in first block

To Reproduce
Steps to reproduce the behavior:

1. Create API request (e.g. with Powershell) against the /api/tools/nextAvailableVNet endpoint with multiple blocks and define a size for which you know, that no such IP range exists anymore in the first block (e.g. Block-001) but ranges are available in the second block (Block-002). Set reverse_search to $false and smalles_cidr to $true.

$body = @{
    space          = 'Azure'
    blocks         = @("Block-001", "Block-002", "Block-003")
    size           = 19
    reverse_search = $false
    smallest_cidr  = $true
} | ConvertTo-Json -Depth 10

Invoke-RestMethod -Method Post `
    -Uri 'https://ipam.azure.six-group.com/api/tools/nextAvailableVNet' `
    -Headers @{
        'accept'        = 'application/json'
        'Authorization' = "Bearer $token"
    } `
    -ContentType 'application/json' `
    -Body $body

Expected behavior
IPAM returns information about the free IP range from Block-002.

Screenshots
Screenshots are attached

Desktop (please complete the following information):

• OS: Windows 11
• Browser: Edge Version
• Version 151.0.4129.59 (Official build) (64-bit)
• PowerShell Version (Invoke_RestMethod): 7.5.4

Additional context

• Issue only appears when first block (Block-001) can't find a free IP range for the requested size
• When another block (e.g. Block-002) is used as first searching block in the API request, it would find a free IP range for the requested size
• IPAM API endpoint /api/tools/nextAvailableVNet theoretically supports an array as input as documented in Azure IPAM - Swagger UI, however, tests have shown that it always returns a Internal Server Error 500 - also seen in the Log stream of the app (see printscreens).
• I was able to narrow down the issue further and have seen that the issue only appears if "smallest_cidr" is set to true. If smallest_cidr is set to false, the API returns a free IP range from the next block (SIX-Azure-010) successfully. It seems to be a code bug when using that feature.
• Also the GUI seems to have issues in this case (see printscreen)