Repository creation repeatedly rolls back with NotSettled on hosted knot #4724

What happened #

On November 8, 2026, creating eptss-atproto under natespilman.at failed twice with:

Failed to create repository: NotSettled > record has not been ingested yet

This blocks publishing an existing local Git repository. No Git push had occurred.

Steps to reproduce #

1. Sign in as natespilman.at.
2. Open https://tangled.org/repo/new?owner=natespilman.at.
3. Enter repository name eptss-atproto, a short description, and default branch main.
4. Keep Hosted by Tangled (knot1.tangled.sh) selected and click Create repository.
5. The form briefly shows “Creating repository…” and then the error above.

The repository did not appear in the account's repository list. A second attempt produced the same error. There was no additional rollback-failure message.

Environment and public checks #

• Web client: tangled.org in the Codex desktop in-app browser.
• Account: natespilman.at (did:plc:c7frv4rcitff3p2nh7of5bcv).
• Current PDS: https://oyster.us-east.host.bsky.network.
• Requested knot: knot1.tangled.sh.
• After the attempts, a direct PDS com.atproto.repo.getRecord lookup for collection org.tangled.repo.declaration, rkey eptss-atproto, returned RecordNotFound.
• Around the investigation, https://api.tangled.org/xrpc/org.tangled.bobbin.getCoverage returned ready: true, stream.state: connected, and stream.lastError: null. That is only a global health signal, not proof this account's records are being ingested.

Source observation, not a confirmed root cause #

In web/src/lib/api/repoCreate.ts at f70c71c, creation mints the knot repository, writes the ownership declaration, and waits via awaitIndexedRecord. The catch path deletes the declaration and then attempts to delete the knot repository.

The observed error and missing declaration are consistent with that rollback path. I have not independently verified knot-side cleanup or the exact deployed web revision.

Expected behavior / request #

Repository creation should complete, or offer an actionable recovery path when indexing times out. Could you check whether this account's declaration writes are reaching the index and advise how to complete creation safely? If the timeout is transient, preserving a recoverable pending creation may be more useful than immediately rolling everything back.

Possibly related: #4654, which involved another account's stale PDS/indexing state. This account uses a Bluesky-hosted PDS; I have not established the same cause here.

Report prepared with AI assistance from the observed UI error, public API checks, and current source.