Skip to content

Fall back to legacy root stellar.toml when .well-known is missing - #890

Merged
Just-Bamford merged 1 commit into
Sorokit:mainfrom
Wycode569:fix/862-sep1-wellknown-fallback
Oct 27, 2026
Merged

Just-Bamford merged 1 commit into
Sorokit:mainfrom
Wycode569:fix/862-sep1-wellknown-fallback

Conversation

@Wycode569

Copy link
Copy Markdown
Contributor

Closes #862

fetchStellarToml (src/integration/sep1Toml.ts) only ever fetched /.well-known/stellar.toml. Domains that predate SEP-1's .well-known standardization and still only serve a bare /stellar.toml at the root returned a 404 and failed discovery entirely.

The standard .well-known path is still tried first and preferred whenever it succeeds (SEP-1 only defines that path; a root-only document was never standard). The legacy root path is attempted only as a fallback when the standard path fails (404, network error, or invalid TOML), so SEP-1-compliant domains are completely unaffected.

Added tests for: well-known tried first, fallback to root on 404, no fallback attempted when well-known succeeds, and both paths failing returning an error. Also fixed 4 existing tests that were reusing the same mocked Response instance across multiple fetchStellarToml calls, previously invisible since only one network call happened per domain, but surfaced by the new fallback path's extra retry hitting an already-consumed Response body.

Documented the resolution order and interaction with cache revalidation in docs/sep1-stellar-toml.md.

Verified against upstream main: npm run typecheck and npm run lint both clean; sep1Toml.test.ts 13/13 passing.

fetchStellarToml only ever fetched /.well-known/stellar.toml, so domains
that predate SEP-1's .well-known standardization and still only serve
a bare /stellar.toml at the root return a 404 and fail discovery
entirely.

.well-known is still tried first and preferred whenever it succeeds;
the legacy root path is only attempted as a fallback when the standard
path fails, so compliant domains are never affected.

Also fixes 4 existing tests that reused the same mocked Response
instance across multiple fetchStellarToml calls in the same test
(valid before, since only one network call happened per domain; the
new fallback path's extra retry on a reused, already-consumed Response
body surfaced the sharing bug) by switching those to a fresh Response
per call via mockImplementation.
@Just-Bamford
Just-Bamford merged commit 13a9323 into Sorokit:main Oct 27, 2026
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StellarTomlResolver does not support .well-known/stellar.toml fallback — fails if TOML is at legacy path

2 participants