Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[release/13.6] Correct context-based endpoint resolution guidance

Open Beginner friendly
  • Is something wrong?
#1,734 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, docker-compose, javascript
Domain
backend, cloud, documentation

Research direction

The file to edit is src/frontend/src/content/docs/architecture/resource-hierarchies.mdx. Start by reading the 'Context-based endpoint resolution' section and the linked issue #1723 to understand the container tunnel behavior. Update the resolution table and the description for DefaultAspireContainerNetwork to correctly reflect the tunnel-enabled and disabled cases, and add a note about the container resource prerequisite. Verify changes by previewing the documentation locally.

Written by the indexing model from the issue text.

Description

docs-from-code

Problem

The Context-based endpoint resolution section in src/frontend/src/content/docs/architecture/resource-hierarchies.mdx contains stale and overgeneralized descriptions that don't account for the container tunnel behavior documented in #1723.

Container-to-host resolution

The current resolution table says:

| Container | Executable / Project | Host network (`host.docker.internal:port`). | `host.docker.internal:5000` |

With the container tunnel enabled—the default behavior—the endpoint is projected through the Aspire container tunnel address, such as aspire.dev.internal:<port>. A container host address such as host.docker.internal:<port> is used when the tunnel is disabled. The table should distinguish these cases rather than presenting the disabled-tunnel behavior as universal.

Default container network description

The current list says:

DefaultAspireContainerNetwork: Resolves to container network URLs using resource names

Resource-name DNS describes container targets, but it doesn't describe project or executable targets. Those endpoints resolve through the container tunnel when enabled, or through the container host name when disabled. The description should define the network identifier as the endpoint's reachability context rather than prescribing one hostname form.

Container resource prerequisite

The section should also explain that the default Aspire container network is created only when the app model contains at least one container resource. Explicitly resolving a project or executable endpoint for DefaultAspireContainerNetwork without any container resources fails with an actionable resource-scoped error.

Expected update

  • Correct the container-to-project/executable row in the resolution table.
  • Qualify the DefaultAspireContainerNetwork description by target resource type and tunnel state.
  • Document the container-resource prerequisite for the default network.
  • Review the surrounding examples and comments for assumptions that all container-network endpoints use resource-name DNS.

This should be fixed in the release/13.6 documentation.

Dominant language
MDX
Stars
195
Forks
91
Avg merge
1d 19h
Merged PRs (30d)
111

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/aspire.dev

All issues in microsoft/aspire.dev

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.