Replace fixed delay with exponential backoff in PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde test

[Copilot]

Summary

Fixes the flaky test Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde by replacing a fixed 2-second delay with exponential backoff polling.

Problem

The test was failing intermittently on macOS CI runners because it used a fixed 2-second delay after calling RunApplicationAsync() before checking if 2 Executables had been created:

await appExecutor.RunApplicationAsync();
await Task.Delay(2000);  // ❌ Fixed delay - too short and source of instability
var dcpExes = kubernetesService.CreatedResources.OfType<Executable>().ToList();
Assert.Equal(2, dcpExes.Count);  // Fails when resources aren't ready yet

This approach had multiple issues:

• Too short: 2 seconds wasn't enough on slower CI machines (especially macOS)
• Inefficient: Always waits full 2 seconds even when resources are ready sooner
• Unreliable: Source of test flakiness

Solution

Replaced the fixed delay with exponential backoff polling using the existing AsyncTestHelpers.AssertIsTrueRetryAsync utility:

await appExecutor.RunApplicationAsync();

// Poll for the expected number of executables with exponential backoff
await AsyncTestHelpers.AssertIsTrueRetryAsync(
    () => kubernetesService.CreatedResources.OfType<Executable>().Count() == 2,
    "Expected 2 executables to be created",
    retries: 12); // ~33 seconds total timeout with exponential backoff

var dcpExes = kubernetesService.CreatedResources.OfType<Executable>().ToList();
Assert.Equal(2, dcpExes.Count);

Benefits:

• ✅ More time: Up to 33 seconds timeout (vs. fixed 2 seconds) to handle slow CI environments
• ✅ Faster happy path: Exits immediately when resources are ready (no unnecessary waiting)
• ✅ Exponential backoff: Delays increase progressively: 50ms, 200ms, 450ms, 800ms, ..., 7200ms
• ✅ Better error messages: Clear failure message if resources never become available
• ✅ Consistent pattern: Uses the same AsyncTestHelpers utility as other tests in the codebase

Testing

Verified that the related test PlainExecutable_ExtensionMode_UnsupportedDebugMode_RunsInProcess still passes with the changes.

Resolves #[issue-number]

Co-authored-by: @karolz-ms

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Failing test: Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde</issue_title>
<issue_description>## Build Information
Build: https://github.com/dotnet/aspire/actions/runs/18602193053
Build error leg or test failing: Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde
Pull request:

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Assert.Equal() Failure: Values differ
Expected: 2
Actual:   1   at Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde() in /Users/runner/work/aspire/aspire/tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs:line 1577
--- End of stack trace from previous location ---

Last 10 failures:

Run date	Test Name
Oct 17 7 PM	[macos] Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde
Oct 17 4 PM	[macos] Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde
Oct 16 4 AM	[macos] Aspire.Hosting.Tests.Dcp.DcpExecutorTests.PlainExecutable_ExtensionMode_SupportedDebugMode_RunsInIde

Summary of the failures

Last 24 hrs	Last 7 days	Last 30 days
2	3	3

-- Updated on 10/17/2025 8:00:27 PM UTC

</issue_description>

<agent_instructions>Please look at my last comment that includes fix suggestion and create a PR that implements it</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@karolz-ms The assert that is failing is in the following test code:

 await Task.Delay(2000);
 // Assert
 var dcpExes = kubernetesService.CreatedResources.OfType<Executable>().ToList();
 Assert.Equal(2, dcpExes.Count);

The fixed delay of 2 seconds is both too small and is the source of test instability. Instead, I suggest probing for correct number of created Executables (2) with exponential backoff and long timeout, e.g. 30 seconds. This will reduce the flakiness AND improve happy path execution time. </comment_new>

Fixes #12133

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.