After rebase onto dd4c390, check_hosts_status on AWS handlers returns CheckHostsStatusResult(instances, fulfilment=ProviderFulfilment(...)) rather than a plain list. The AWS strategy unwraps .fulfilment and writes provider_fulfilment into request metadata; without that key, RequestStatusService raises ProviderContractError on every status poll for in-flight AWS requests. The Azure strategy routes via a fully async dispatch and never calls the sync check_hosts_status directly, so there's no runtime failure for Azure, but the PR's AWS strategy path needs to be reconciled with the main contract.

BLOCKER - fulfillment_final: True with instances: [] and provisioning_state: "creating" is contradictory. provisioning_orchestration_service.py computes is_final = (not has_capacity_error and len(instances) >= count) or fulfillment_final. With fulfillment_final=True this short-circuits immediately: the request is marked terminal on the first poll cycle with zero machines registered and is never polled again. VMSS provisions asynchronously, so the intent is clearly "poll via status checks", but this flag signals "done". Set fulfillment_final: False here so the count-based path drives termination. The existing tests don't catch this because none of them run the acquire result through the orchestration service.

VMSS and SingleVM do set fulfillment_final=True on create submission. This is intentional, it stops the provisioning retry/top-up loop so no more create attempts are made after submitting the provider resource while Azure is creating the resources. However, the persisted request-status update still sets a successful request with resource_ids and zero instances to IN_PROGRESS, not completed or failed.

The request does not resolve immediately with zero machines. It remains pending for later status synchronization. It is updated to completed or failed later via the follow up context.

AllocationStrategy is legitimately shared - AWS EC2 Fleet uses LOWEST_PRICE/DIVERSIFIED/CAPACITY_OPTIMIZED and Azure uses SPOT_PLACEMENT_SCORE, so keeping it in domain/base/ is correct. PlacementSplitStrategy (GREEDY/HYBRID) is Azure-only: it encodes Azure spot-placement scoring splits and is unused outside providers/azure/. Move it to providers/azure/domain/ before merge.

This does not seem to be true? I have synced main to get the update, but it does not have an AllocationStrategy.

Security (Medium) - cyclecloud_credential_path is written into request metadata that gets persisted. Any API response surfacing request metadata (e.g. GET /requests/{id}/status) exposes a host filesystem path to callers. Store a logical alias or config key instead of the raw path. The field is already repr=False on CycleCloudCredentialData.password; applying the same treatment here would at least prevent it appearing in logs, but the metadata persistence risk remains.

Security (Medium) - file_path comes from template.provider_api_spec_file, which is operator-supplied. No check that os.path.realpath(f"{base_path}/{file_path}") starts with os.path.realpath(base_path) before the read. A value like ../../etc/passwd reads outside the intended directory. AWS AWSNativeSpecService._load_spec_file has the same pattern, so this is a parity fix for both providers: validate containment before calling read_json_file.

Do you want me to fix AWS as well? I assumed copying this pattern was fine as it is operator provided data, sorry.

Use logger.debug rather than logger.info here. Credential initialisation is operational noise at INFO level, and if a client_id or similar field is ever interpolated into this message it becomes an info-disclosure risk in environments where INFO logs are forwarded externally.

Security (Low) - azure-mgmt-resource-subscriptions>=1.0.0b1 is a pre-release dependency with no stable release. Beta SDKs carry API-stability and supply-chain risk in production. Pin to the specific beta version currently validated rather than an open >= floor, and track the GA release to migrate.

PROVIDER1 = "provider1" and Provider2 = "provider2" are placeholder stubs. They'll appear in every CLI completion, API response listing provider types, and any exhaustive-match check. Drop both before merge - if additional providers are planned, they can be added when the implementation exists.

vm_size and vm_sizes are Azure-specific field names - AWS uses instance_type/instance_types. The base Template aggregate is shared across all providers; adding Azure vocabulary here means every GCP or other provider inherits these fields without asking. Move vm_size, vm_sizes, and the placement_* fields below to AzureTemplate(Template) in providers/azure/domain/template/. AzureTemplate already redefines vm_size as a required str, so the move is mostly mechanical.

PlacementSplitStrategy encodes Azure spot-placement scoring split logic (greedy vs hybrid). Nothing outside providers/azure/ uses it. Move to providers/azure/domain/ so the shared domain layer stays provider-agnostic. AllocationStrategy above is legitimately shared and can stay.

While this is only currently implemented for azure, nothing about it seems inherently azure?

except Exception: raise is a no-op - it catches and immediately re-raises without doing anything. The self._logger.debug(...) call on the next line is unreachable on any exception path. Remove the try/except entirely and keep just the await resource.close() and the debug log.

The TODO comment correctly identifies that get_active_strategy() doesn't exist on SchedulerRegistry and raises AttributeError at runtime - the outer try/except silently swallows it and always falls back to hardcoded templates. This code path has never executed. Either implement get_active_strategy() on the registry or delete the unreachable branch and call get_fallback_templates() directly. Shipping known-broken code with a TODO is a maintenance trap.

This is an issue shared with AWS, but I wasn't confident enough about the intent to implement the method myself. I wanted to ensure that the Azure provider did not behave incorrectly once it was implemented.

register_azure_extensions() wires CLISpecRegistry, TemplateExtensionRegistry, and ProviderSettingsRegistry - three of the five registries main introduced. AuthRegistry and DefaultsLoaderRegistry are not called. AWS does both in register_aws_auth_strategies() and registers AWSDefaultsLoader in registration.py. AzureAuthStrategy exists in providers/azure/auth/ but is unreachable via the AuthRegistry lookup path. Add register_azure_auth_strategies() and at minimum an empty AzureDefaultsLoader so the registry contracts are fulfilled symmetrically.

After rebase, please put the Azure SDKs under an [azure] optional-dependencies extra rather than the core [project.dependencies] list. Main has the pattern in place: [aws] exists as an opt-in alias for boto3, [all-providers] is a meta-extra. With 9 azure-* SDKs in core, every non-Azure deployment pulls in ~hundreds of MB of unused transitive deps. Add azure = [...] under [project.optional-dependencies] and extend all-providers to ["orb-py[aws,azure]"].

This is not used in a security-relevant context, do I still need to address it to satisfy the scanner?