test(hosting): fix Outerloop tests asserting null proxyless EffectivePort - #18249
test(hosting): fix Outerloop tests asserting null proxyless EffectivePort#18249Ankit Jain (radical) wants to merge 1 commit into
Conversation
ProxylessContainerCanBeReferenced and WithEndpointProxySupportDisablesProxies
([OuterloopTest], Docker-required) failed every scheduled Outerloop run on the
Hosting (8-core-ubuntu-latest) job while passing on Windows:
Assert.IsType() Failure: Value is null
Expected: typeof(int)
Actual: null
at ...AssertAllocatedProxylessPort(Service service) line 2319
at ...ProxylessContainerCanBeReferenced() line 1835
Both assert on the redisNoPort proxyless service's Status.EffectivePort.
PR microsoft#17924 made Aspire pre-assign the proxyless host port synchronously
(Service.Spec.Port) and deliberately excluded proxyless services from the
startup address-wait in DcpExecutor, since connection strings use the
Aspire-assigned Spec.Port immediately. DCP still echoes the bound port back
asynchronously via Status.EffectivePort. On a fast Linux agent the test reads
the service list before DCP populates EffectivePort, so the assertion sees
null; on Windows the update lands first, so it passes. The unit-test fake sets
EffectivePort = Spec.Port synchronously, hiding the race.
Fix is test-side: wait for the proxyless service to report a non-null
EffectivePort (via KubernetesHelper.GetResourceByNameAsync, the existing
watch-based waiter) before asserting, instead of reading a once-fetched
service list. No product change - the orchestrator behavior is correct.
Fixes microsoft#8773
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18249Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 18249" |
There was a problem hiding this comment.
Pull request overview
This PR fixes two deterministically failing [OuterloopTest] tests on Linux CI (ProxylessContainerCanBeReferenced and WithEndpointProxySupportDisablesProxies) that fail because DCP hasn't yet populated Service.Status.EffectivePort when the test assertion runs. The root cause is that PR #17924 intentionally excluded proxyless services from the DCP startup address-wait (since connection strings use the synchronously-assigned Spec.Port), but the tests asserted against EffectivePort from a one-shot list fetch, creating a race condition on fast Linux CI agents.
Changes:
- Replaced the synchronous
GetEndpointService(serviceList, ...)helper with a newWaitForAllocatedProxylessServiceAsyncthat uses the existing watch-basedKubernetesHelper.GetResourceByNameAsyncto wait until DCP populatesEffectivePort. - Removed the now-unnecessary
serviceListfetch fromProxylessContainerCanBeReferenced(the second test retains it for an unrelatedAssert.Allassertion).
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Consolidating the unapproved Outerloop test fixes into a single PR: #18250. Closing in favor of that one (same change, preserved authorship). |
The Outerloop Tests workflow fails every scheduled night (7/7 this week, flagged in #18223). Two
[OuterloopTest]+ Docker-required Hosting tests fail deterministically on theHosting (8-core-ubuntu-latest)job and pass onwindows-latest:Aspire.Hosting.Tests.DistributedApplicationTests.ProxylessContainerCanBeReferencedAspire.Hosting.Tests.DistributedApplicationTests.WithEndpointProxySupportDisablesProxiesBoth fail the same way:
Root cause
Both tests assert on the
redisNoPortproxyless service'sStatus.EffectivePort. PR #17924 ("Add proxyless endpoint port allocator") made Aspire pre-assign the proxyless host port synchronously (Service.Spec.Port) and intentionally excluded proxyless services from the startup address-wait inDcpExecutor— connection strings are built from the Aspire-assignedSpec.Port, which is available immediately, so startup need not block on DCP echoing the bound port.DCP still reports that port back asynchronously via
Status.EffectivePort. AfterStartAsync()and the app responding, DCP may not yet have populatedEffectivePortfor the proxyless service. The fast 8-core Linux runner reads the service list before that update lands → null; Windows lands the update first → pass. The unit-test fake setsEffectivePort = Spec.Portsynchronously, so unit tests never hit the race.This is a test bug, not a product regression — the orchestrator behavior is correct by design.
The fix
Test-side only. Both tests now wait for the proxyless service to report a non-null
Status.EffectivePort(usingKubernetesHelper.GetResourceByNameAsync, the existing watch-based waiter already used elsewhere in this file) before runningAssertAllocatedProxylessPort, instead of asserting against a once-fetched service list. This preserves the end-to-end check that DCP actually bound the Aspire-assigned port. No product code changes.Call-outs
WithEndpointProxySupportDisablesProxiesis not yet tracked by an issue; it shares the exact same root cause and is fixed by the same change.DcpExecutor's intentional proxyless exclusion is unchanged.Fixes #8773