A BlueSky reply can exist as a repository record and still be hard to see immediately in a public thread view. That does not always mean the post failed. It can mean the thread pointers are wrong, the AppView has not indexed the record yet, or the viewer is seeing a blocked, deleted, or not-found branch.
The first step is to separate three questions: did the PDS create the record, did the record include a valid reply object, and did the AppView or client render the updated thread yet?
Read BlueSky's read-after-write guide for why recent records may not immediately appear in AppView responses.
Check the reply object first
A reply needs two strong references: root and parent. The root points to the original post in the thread. The parent points to the immediate post being answered. Each strong reference includes both the AT URI and CID.
Use the BlueSky thread root and parent pointer builder to inspect the reply shape before custom API publishing.
Understand AppView indexing delay
BlueSky's read-after-write documentation explains that services such as the AppView are eventually consistent because they do not have transactional writes from a user's PDS. The record can be on the PDS before every derived view has caught up.
The guide also explains that the PDS can smooth some routes by comparing AppView response headers with local records, but this behavior is not universal for every viewer or every account involved in the thread.
Use getPostThread correctly
The thread viewer route accepts depth and parentHeight parameters. A shallow fetch can make a real branch look missing. A blocked, deleted, or moderated post can also appear as a blocked or not-found state while still preserving enough shape for clients to render the tree.
- Fetch the root post and inspect replies with adequate depth.
- Fetch the child post directly and inspect parentHeight.
- Confirm the root and parent strong references point to the intended records.
- Check whether any branch is blocked, deleted, moderated, or not found.
- Wait for AppView indexing before retrying or duplicating the reply.
Why duplicate retries make threads worse
A common mistake is reposting the same reply because the first one did not show immediately. If the original record later appears, the thread can contain duplicate children, confusing readers and making the account look automated.
For scheduled launches, keep a publish log with post URI, CID, parent, root, createdAt, and retry state. That gives the team a way to verify the record before posting another copy.
Where ONYX fits
ONYX reduces this failure mode by treating multi-post threads as planned content, not a pile of manual retries. Draft the sequence, split the posts, review the order, schedule the approved thread, and keep the publishing state visible.
A consistent posting rhythm also gives followers more chances to reply naturally. That does not eliminate relay or AppView timing, but it keeps the creator from reacting to temporary visibility lag with rushed duplicate posts.
Use the BlueSky thread splitter before complex posts enter the approved ONYX queue.