Document Azure Sandbox previous-generation retention conditions
- Dominant language
- C#
- Stars
- 6.3k
- Forks
- 991
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 196
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Describe the work
The Azure Sandboxes README introduced in #19008 describes previous-generation URL retention as depending on the immutable image and endpoint policy:
> To keep endpoint references usable during an ordinary redeploy of the same immutable image and endpoint policy, Aspire can retain the immediately previous sandbox generation...
The implementation has additional conditions. `HasSecurityRelevantEndpointChange` forces immediate pruning when the current or previous deployment has AppHost-resolved runtime environment configuration or modeled command configuration, even when the image and endpoint settings are otherwise unchanged. This conservative behavior avoids retaining a generation that may contain different resolved secrets, endpoint values, arguments, or commands without persisting those sensitive values for comparison.
The current wording can therefore lead users to expect endpoint continuity for common workloads that use environment variables or `WithArgs`, while those deployments intentionally prune the previous generation.
### Expected outcome
Update `src/Aspire.Hosting.Azure.Sandboxes/README.md` to document all retention conditions accurately:
- image digest and endpoint/security policy must be unchanged,
- deployments with resolved runtime environment values or modeled command configuration are conservatively treated as changed,
- removing previously configured runtime environment/command state triggers one final prune,
- and mandatory cleanup failure keeps the deployment visibly failed while preserving retry state.
Keep the explanation concise and security-focused; do not expose or recommend persisting secret-derived hashes merely to compare values.
Review related XML documentation and deployment summary wording for the same assumption. Add or retain focused tests that make the documented retention/pruning matrix explicit.
### Additional context
Follow-up from #19008 and the suppressed Copilot review finding on `README.md:92`. This is documentation accuracy for an experimental deployment target, not a merge/build blocker.
Contributor guide
Research direction
Start with src/Aspire.Hosting.Azure.Sandboxes/README.md and the HasSecurityRelevantEndpointChange behavior described in the issue. Review related XML documentation and deployment summary wording, then inspect focused sandbox tests for the retention and pruning matrix. Done means the documented conditions match the implementation, including conservative pruning and mandatory-cleanup failure behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp
- Domain
- cloud, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100