[Automated] Update API Surface Area#3
Closed
github-actions[bot] wants to merge 11 commits intomainfrom
Closed
Conversation
github-actions
Bot
force-pushed
the
update-api-diffs
branch
from
8635401 to
323de02
Compare
radical
force-pushed
the
main
branch
2 times, most recently
from
6fe6e8a to
f8f4c34
Compare
radical
pushed a commit
that referenced
this pull request
Dec 5, 2025
…e proxy scenarios (microsoft#13036) * Relax path validation for ExternalServiceResource to support reverse proxy scenarios (#3) * Initial plan * Relax path validation for ExternalServiceResource - Update ExternalServiceResource.GetUriValidationException to accept paths ending with '/' - Update ResourceBuilderExtensions.WithReference validation similarly - Update XML documentation to reflect new requirement - Add comprehensive test coverage for path validation - Update existing tests to match new error messages Co-authored-by: sliekens <1583241+sliekens@users.noreply.github.com> * Reject query strings in external service URIs - Add validation to reject URIs with query strings, similar to fragments - Query strings should not be part of the base URI for HttpClient - Update tests to reflect query string rejection - Move query string test cases from valid to invalid - Add dedicated test for query string rejection Co-authored-by: sliekens <1583241+sliekens@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: sliekens <1583241+sliekens@users.noreply.github.com> * Clarify URI requirements in ExternalServiceResource documentation * Align URL validation between ExternalServiceResource and ad-hoc URLs --------- Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: sliekens <1583241+sliekens@users.noreply.github.com>
radical
added a commit
that referenced
this pull request
May 6, 2026
…ityChannelReader DI wiring The CliBootstrapTests previously contained a snapshot test (IIdentityChannelReader_NotYetRegisteredInProductionDI_BootstrapWiringIsPendingFollowUp) that asserted, via reflection, the absence of any production consumer of IIdentityChannelReader. With PR1-S12 (1dc0dde) wiring the reader into Program.BuildApplicationAsync's DI container, that snapshot now flips and must be replaced with positive coverage of the wiring contract. New coverage in tests/Aspire.Cli.Tests/CliBootstrapTests.cs: * IIdentityChannelReader_TypeExists_AndProductionImplementationShape (kept, lightly renamed) — locks the interface + IdentityChannelReader ctor signature so the production factory delegate stays bound to a stable contract. * IdentityChannelReader_OnRunningCliAssembly_ReturnsKnownChannel (kept) — the Aspire.Cli assembly's baked AspireCliChannel value resolves to one of stable/staging/daily/pr. * BuildApplication_RegistersIIdentityChannelReader_AsIdentityChannelReaderInstance (new) — host.Services.GetRequiredService<IIdentityChannelReader>() resolves to an IdentityChannelReader instance (AC #1 from livingston-pr1-bootstrap-wire-needed.md step 5). * BuildApplication_PopulatesCliExecutionContextChannel_FromIdentityChannelReader (new) — context.Channel matches reader.ReadChannel(); the context's channel was sourced from the reader, not from the constructor default (AC #2). This is the assertion that catches a regression where the PR1-S10 reseed chain would silently write "daily" for every CLI build regardless of the baked channel. * BuildApplication_LocallyBuiltCli_HasDailyChannelAndNullPrNumber (new) — for a locally-built CLI (default csproj AspireCliChannel=daily, no -pr suffix in InformationalVersion), context.Channel == "daily" and context.PrNumber is null (AC #3 + the additional PrNumber assertion from the spec). * BuildApplication_CliExecutionContextChannel_MatchesAssemblyMetadataAttribute (new) — end-to-end coherence: the channel flowing through DI equals the value baked into the entry assembly's [AssemblyMetadata("AspireCliChannel")] via reflection — independent of the constant "daily". The new tests use the same pattern as the existing TelemetryConfigurationTests.BuildHostAsync — they invoke the real Program.BuildApplicationAsync so the assertions exercise the production factory delegate, not a duplicated test copy. Test-csproj change (Aspire.Cli.Tests.csproj): The default IdentityChannelReader reads AspireCliChannel from Assembly.GetEntryAssembly(). In production this is Aspire.Cli.dll (which has the metadata baked in by Aspire.Cli.csproj). Under `dotnet test` the entry assembly is the test host (Aspire.Cli.Tests.dll), which had no metadata, so the bootstrap factory threw on first resolution of CliExecutionContext. Adding <AssemblyMetadata Include="AspireCliChannel" Value="daily" /> to the test csproj mirrors production, so any test that resolves CliExecutionContext from a real Program.BuildApplicationAsync host gets a coherent "daily" channel value (and PrNumber null, since Aspire.Cli's InformationalVersion under dev builds has no -pr<N> suffix). Note on a follow-up concern: Linus's PR1-S12 wiring uses Assembly.GetEntryAssembly() (via the default IdentityChannelReader ctor) for Channel but typeof(Program).Assembly for InformationalVersion / PrNumber. In production both resolve to Aspire.Cli.dll and that is fine, but the asymmetry is fragile under any future hosting scenario where GetEntryAssembly() != typeof(Program).Assembly (tests, custom hosts). This isn't blocking PR1 closure — flagging it for a follow-up decision drop after the PR1 wave merges. Build + test: dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj \ --no-launch-profile -- \ --filter-class "*.CliBootstrapTests" \ --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true" -> 6 passed, 0 failed (1.2s) Also re-ran adjacent suites that share BuildApplicationAsync to confirm no regression: AssemblyMetadataChannelTests + CliExecutionContextTests + CliBootstrapTests + TelemetryConfigurationTests = 26 passed, 0 failed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
1 participant
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.
Auto-generated update to the API surface to compare current surface vs latest release. This should only be merged once this surface area ships in a new release.