Azure: UnboundLocalError in _add_machines_to_db() when VMSS has zero instances (initial_pool_size=0)

[xtarget]

Title

[Azure] Zero-Scale and external VMSS management fixes

Summary

Fixes three related bugs that prevent zero-scale configurations (initial_pool_size=0) and external VMSS management (just_star

Environment: CAPEv2 Latest (main), Azure VMSS, Python 3.13

Bugs Fixed

Bug #1: _add_machines_to_db throws ResourceNotFoundError (capacity=0)

File: modules/machinery/az.py, Line 780
Issue: Method throws unhandled ResourceNotFoundError when iterating over network interfaces of empty VMSS
Fix: Add try-except block around paging iterator with ResourceNotFoundError handler

Bug #2: _delete_machines_from_db_if_missing throws ResourceNotFoundError (capacity=0)

File: modules/machinery/az.py, Line 815
Issue: Method throws unhandled ResourceNotFoundError when listing VMs in empty VMSS
Fix: Add try-except block around paging iterator with ResourceNotFoundError handler

Bug #3: _process_pre_existing_vmsss ignores just_start parameter

File: modules/machinery/az.py, Line 343
Issue: Method deletes externally created VMSS without checking just_start parameter
Fix: Add just_start check before deleting VMSS, add logging for delete operations

Changes

• Add exception handling for capacity=0 in _add_machines_to_db
• Add exception handling for capacity=0 in _delete_machines_from_db_if_missing
• Add just_start check in _process_pre_existing_vmsss
• Add logging for VMSS delete operations
• Ensure ResourceNotFoundError is imported from azure.core.exceptions

Impact

• Zero-scale feature (initial_pool_size=0) works correctly
• External VMSS management (Ansible/Terraform) with just_start=true works
• VMSS remains stable with capacity=0 (no deletion loop)
• Cost savings: ~€40-60/month when using zero-scale vs. always-on VMSS

Testing

Tested scenarios:

• VMSS with capacity=0 (zero-scale): No exceptions, VMSS stable
• VMSS with capacity=1: Normal operation works
• External VMSS with just_start=true: VMSS not deleted on startup
• All scenarios: CAPEv2 starts without crashes, tasks can be submitted

Related Issues

• Azure: UnboundLocalError in _add_machines_to_db() when VMSS has zero instances (initial_pool_size=0) #2842: UnboundLocalError when VMSS has capacity=0
• [Azure] Zero-Scale fails: _delete_machines_from_db_if_missing throws ParentResourceNotFound when VMSS has capacity=0 #2848: Zero-Scale feature non-functional
• Related to PR Azure machinery major updates #2666: Zero-Scale feature introduction

[doomedraven]

hey, thanks, can you PR suggested fix please? azure is commuity maintained module, we don't use it

[xtarget]

Hey, sure — I’ll open a PR with the suggested fix shortly.

[doomedraven]

#2853

[xtarget]

Hi @doomedraven,

Thank you for PR #2853! I've been working on Azure zero-scale functionality
and created patches for 13 bug fixes. I noticed that 2 of them (#2 and #4)
are duplicates of your changes:

• Bug Add description #2: ResourceNotFoundError handling (identical to your fix)
• Bug Add submission of vhd files #4: just_start parameter respect (identical to your fix)

The remaining 11 bugs address critical zero-scale issues including:

• Bug Update agent.py #8: Zero-scale doesn't work (acquire() logic fix)
• Bug Proper modern clamav support, and a couple of sig fixes. #11: Scaling-flag race condition (THE BLOCKER)
• Bug Add SNAKE, edit Clop #12: VM deleted while task running (THE SILENT KILLER)
• And 8 more zero-scale specific fixes

Zero-scale is working on my testing system. I'm currently verifying the
complete functionality on my Azure test environment.

Once I've verified everything works correctly, I will:

1. Adapt my patches to your code (removing bugs Add description #2 and Add submission of vhd files #4)
2. Update the remaining fixes based on the current situation at that time
3. Submit them as separate PRs

This approach avoids conflicts and ensures clean integration.

Best regards

[doomedraven]

thank you for update and working on it!

[doomedraven]

if that fine for you i can merge my fix or i can wait for your and merge your and close mine, what best works for you

[xtarget]

Please go ahead and merge your PR #2853! Don't wait for mine.

Your fixes are important stability improvements that should go in immediately.
My remaining 11 zero-scale fixes are independent and can be submitted later
as separate PRs on top of your changes.

This is the cleanest approach:

1. Your PR Improve Azure VMSS error handling and logging #2853 gets merged now (stability + error handling)
2. I verify my fixes against your merged code
3. I submit my 11 remaining fixes as separate PRs

No need to delay your good work - let's get it merged!

Thanks again for the great improvements.

Best regards

[doomedraven]

Merged El jue, 22 ene 2026, 14:33, xtarget ***@***.***> escribió:

…

*xtarget* left a comment (kevoreilly/CAPEv2#2842) <#2842 (comment)> Please go ahead and merge your PR #2853 <#2853>! Don't wait for mine. Your fixes are important stability improvements that should go in immediately. My remaining 11 zero-scale fixes are independent and can be submitted later as separate PRs on top of your changes. This is the cleanest approach: 1. Your PR #2853 <#2853> gets merged now (stability + error handling) 2. I verify my fixes against your merged code 3. I submit my 11 remaining fixes as separate PRs No need to delay your good work - let's get it merged! Thanks again for the great improvements. Best regards — Reply to this email directly, view it on GitHub <#2842 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOFH3YOJ4JK2UZAM5CTN3L4IDGT7AVCNFSM6AAAAACRQ6WKFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOBUGQ2DKMRXGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>