Incident Notes

After a PDS migration for @zat.dev, multiple systems appear to have disagreed about the account/repo state for a period of time.

The original public symptom was that Bluesky’s appview treated @zat.dev as deactivated, while Blacksky did not. In the thread, Jim later noted that “something got gunked up in the relay in pop2,” that pop1 looked fine, and that manually setting the account status active plus rebooting the relay cleared caches.

Separately, Tangled is now showing related-looking state drift around the zat.dev/zat repository.

What we observed live:

• did:plc:mkqt76xvfgxuemlwlx6ruc3w currently resolves to PDS https://pds.zat.dev.
• The PLC audit log shows the DID moved to https://pds.zat.dev on June 2, 2026.
• The repo record currently exists on the migrated PDS at:

at://did:plc:mkqt76xvfgxuemlwlx6ruc3w/sh.tangled.repo/3mbqdqijxo522

• That record has:
  • name: "zat"
  • repoDid: "did:plc:wkf7mpx6vtimg54hcdl7suww"
  • spindle: "spindle.tangled.sh"
  • website: "https://zat.dev"
• Querying the old/name-like rkey fails:

at://did:plc:mkqt76xvfgxuemlwlx6ruc3w/sh.tangled.repo/zat

returns RecordNotFound.

The Tangled UI errors line up with that mismatch.

When selecting the hosted spindle, Tangled reports:

Failed to update spindle, no record found on PDS.

In core, that path resolves the repo from Tangled’s app state, then calls com.atproto.repo.getRecord using the stored repo owner DID and stored repo rkey before writing the updated spindle field. If that stored rkey is zat, the PDS lookup fails even though the actual repo record exists under 3mbqdqijxo522.

The secret-setting flow appears to fail for the same reason. Appview sends the repo AT URI to the spindle XRPC. The spindle then dereferences that AT URI against the owner’s current PDS in order to extract repoDid and check permissions. If the URI contains stale rkey zat, the spindle also sees RecordNotFound.

So the working theory is:

Tangled has enough current state to display zat.dev/zat, and the PDS has the repo record, but at least one backend path is still using a stale repo record rkey. This resembles the earlier Bluesky/relay issue in that the underlying account/PDS state is valid, while a consumer/cache/indexer has retained or reconstructed stale post-migration state.