Repository navigation
Extend DCP initialization timeout through API readiness - #19641
Conversation
Keep the initialization retry budget until an eager DCP API call succeeds, then use the normal steady-state budget. Propagate timeout cancellation into the Kubernetes client calls and cover both transitions. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2faf8d87-e20d-4c7c-95cf-07abd6179e13
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19641Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19641" |
github-actions
Bot
added
the
needs-area-label
There was a problem hiding this comment.
Pull request overview
Extends DCP initialization handling until the first successful API operation.
Changes:
- Propagates Polly cancellation tokens to Kubernetes requests.
- Tracks API readiness and adds timeout regression tests.
Show a summary per file
| File | Description |
|---|---|
src/Aspire.Hosting/Dcp/KubernetesService.cs |
Extends startup retry handling through API readiness. |
tests/Aspire.Hosting.Tests/Dcp/KubernetesServiceTests.cs |
Tests readiness, steady-state timeout, and cancellation. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
This comment has been minimized.
This comment has been minimized.
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
Karol Zadora-Przylecki (karolz-ms)
left a comment
Karol Zadora-Przylecki (karolz-ms)
left a comment
There was a problem hiding this comment.
Idea is good but the code can be simplified--HTH
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 14e6fead-9dad-4880-bdaf-75663b728b67
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 14e6fead-9dad-4880-bdaf-75663b728b67
Tests selector (audit mode)The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement. 50 / 102 test projects · 4 jobs, from 2 changed files. Selected test projects (50 / 102)
Selected jobs (4)
How these were chosen — grouped by what changed
🔧 show 45
🧪 📦 affected project Job reasons
Selection computed for commit |
There was a problem hiding this comment.
Review details
Suppressed comments (1)
src/Aspire.Hosting/Dcp/KubernetesService.cs:494
- The readiness state is sampled only after client initialization has awaited. A concurrent call that began while DCP was not ready can therefore observe
trueif another operation succeeds during that wait and receive onlyMaxRetryDuration, contrary to the stated requirement that calls started before readiness retain the startup budget. This is reachable becauseDcpResourceWatcher.Start()launches five watches concurrently. Capture the readiness state once atExecuteWithRetryentry, before any await, and use that snapshot when selecting the retry duration.
var retryDuration = Volatile.Read(ref _kubernetesApiReady)
? MaxRetryDuration
: KubernetesInitializationTimeout;
- Files reviewed: 2/2 changed files
- Comments generated: 0 new
- Review effort level: Balanced
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
✅ No documentation update needed. Step 5 branch taken: Triggered signals: no signals triggered ( Allowlist justification ( |
|
The CI build failed due to test failure(s) that appear unrelated to the PR changes. These may be flaky tests. Suspected flaky test(s): Suggested actions:
You can re-run the failed jobs from the workflow run page. |
Description
#19636 gave initial DCP kubeconfig discovery and client creation a separate 60-second timeout, but its first CI run still timed out in the first DCP API operation after the client was initialized. A parsed kubeconfig does not mean DCP is ready to process requests yet.
This keeps the startup timeout through the first successful eager DCP API operation. Calls that start before readiness retain that startup budget; later calls use the existing 20-second retry budget. Lazy watches do not publish readiness, and Polly's timeout token now reaches the underlying Kubernetes requests so stalled requests are canceled.
The regression coverage now checks delayed kubeconfig creation, delayed first API success, the transition back to the steady-state timeout, and cancellation of a stalled HTTP request.
Follow-up to #19636.
Checklist
<remarks />and<code />elements on your triple slash comments?