Description

In a TypeScript AppHost on Aspire 13.2.0, using withEnvironmentEndpoint(...) with an endpoint reference returned from getEndpoint('https') on a Python Uvicorn app can cause dependent resources to fail with FailedToStart before the process is spawned, with no useful diagnostics.

The difficult part was that the failure mode looks like a resource launch problem with no explanation:

• resource state becomes FailedToStart
• executable.pid is null
• no exit code
• environment is empty in aspire describe
• aspire logs <resource> has little or nothing useful
• aspire otel logs is empty
• apphost/CLI trace logs do not show a clear validation or endpoint-resolution error

What appears to be happening is that endpoint resolution fails during environment construction, before Aspire attempts to start the target process.

Environment

• Aspire CLI: 13.2.0+30d3d9727935d9089d6bc0a4fd40eac3d4ab04a9
• TypeScript AppHost
• Aspire.Hosting.Python 13.2.0
• Aspire.Hosting.JavaScript 13.2.0
• Windows

Minimal pattern

This is the relevant shape of the apphost:

const boston = await builder.addUvicornApp('api-boston', './api-boston', 'main:app')
  .withUv();

const bostonEndpoint = await boston.getEndpoint('https');

const advisor = await builder.addUvicornApp('api-advisor', './api-advisor', 'main:app')
  .withUv()
  .withEnvironmentEndpoint('services__api-boston__https__0', bostonEndpoint);

await builder.addViteApp('frontend', './frontend')
  .withHttpsEndpoint({ env: 'PORT' })
  .withHttpsDeveloperCertificate()
  .withEnvironmentEndpoint('services__api-advisor__https__0', await advisor.getEndpoint('https'))
  .withEnvironmentEndpoint('services__api-boston__https__0', bostonEndpoint);

Actual behavior

api-advisor and frontend fail to start with no PID and no meaningful diagnostics.

Expected behavior

One of these should happen:

1. getEndpoint('https') should work if the resource is exposed over HTTPS.
2. If https is not a valid endpoint name for that resource, Aspire should fail fast with a clear validation error in the apphost output, such as which resource and endpoint name were invalid.
3. aspire describe / aspire logs should surface the configuration failure instead of only showing FailedToStart with no PID / exit code.

What made this confusing

For the affected Uvicorn resources, the resulting URLs were HTTPS, but the endpoint name that actually worked was still http.

Changing the code to this fixed the issue immediately:

const bostonEndpoint = await boston.getEndpoint('http');
const advisorEndpoint = await advisor.getEndpoint('http');

while still injecting them into env vars named like:

.withEnvironmentEndpoint('services__api-boston__https__0', bostonEndpoint)
.withEnvironmentEndpoint('services__api-advisor__https__0', advisorEndpoint)

So from the user perspective:

• the resource is reachable over HTTPS
• the env var naming convention suggests HTTPS
• but getEndpoint('https') appears invalid
• and the failure is almost completely silent

Suggested improvement

At minimum, Aspire should emit a clear error when an invalid endpoint name is used in getEndpoint(...) / withEnvironmentEndpoint(...), ideally before resource startup begins.

Some kind of message like this would have saved a lot of time:

Resource api-boston does not expose an endpoint named https. Available endpoints: http.

If helpful, I can provide a smaller standalone repro.