fix: add pre-create NIC readiness gate before New-HNSNetwork to avoid windows race condition#8008
Merged
timmy-wright merged 17 commits intomainfrom Mar 5, 2026
Merged
fix: add pre-create NIC readiness gate before New-HNSNetwork to avoid windows race condition#8008timmy-wright merged 17 commits intomainfrom
timmy-wright merged 17 commits intomainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Addresses a Windows node provisioning race where New-HNSNetwork can latch an APIPA address as ProviderAddress if the primary NIC is still transitioning to its DHCP address.
Changes:
- Add a pre-create readiness gate in
New-ExternalHnsNetworkto wait (up to 120s) for a stable, non-APIPA IPv4 inPreferredstate before callingNew-HNSNetwork. - Add Pester tests for the new readiness-gate behaviors and dual-stack invocation shape.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| staging/cse/windows/azurecnifunc.ps1 | Adds pre-create polling gate to avoid HNS latching APIPA ProviderAddress during NIC transition. |
| staging/cse/windows/azurecnifunc.tests.ps1 | Adds Pester coverage for the readiness gate and dual-stack New-HNSNetwork call pattern. |
awesomenix
approved these changes
Mar 4, 2026
awesomenix
reviewed
Mar 4, 2026
Devinwong
approved these changes
Mar 4, 2026
awesomenix
reviewed
Mar 4, 2026
awesomenix
approved these changes
Mar 4, 2026
Devinwong
approved these changes
Mar 4, 2026
janenotjung-hue
pushed a commit
that referenced
this pull request
Mar 11, 2026
… windows race condition (#8008)
saewoni
pushed a commit
that referenced
this pull request
Mar 20, 2026
… windows race condition (#8008)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When
New-HNSNetworkis called while the primary NIC is still transitioning from its APIPA (169.254/16) address to its DHCP address, HNS latches the APIPA address asProviderAddress. Since HNS doesn't proactively updateProviderAddressafter creation, this persists and causes node provisioning failures.Fix
Added a pre-create readiness gate in
New-ExternalHnsNetwork(azurecnifunc.ps1) that polls the chosen network adapter for a stable, non-APIPA IPv4 address inPreferredstate before callingNew-HNSNetwork. The gate:Get-NetIPAddressevery 500ms, up to 120 secondsPreferredIP is foundTests
Added
Describe 'New-ExternalHnsNetwork'Pester tests covering:New-HNSNetworkcalled onceNew-HNSNetwork