[SanderMuller]

A thread loads replies in three places. They are the first load, reload() after a post, delete or undo, and loadUntil() behind the more-replies button and "Show all". Each one writes its result when it arrives, so an older response can overwrite a newer one. For example, if you post a reply while more replies are still loading, the reload shows your reply. Then the late page replaces the list, and your reply is gone until the next reload. Two quick deletes can bring a deleted reply back the same way.

Each request now takes an id. Only the latest one writes its page to the list and the reply count, and clears isLoading.

ThreadReplies.test.tsx runs useThread with fake fetches that resolve out of order. It covers a late page from the more-replies button and two overlapping reloads, which both fail on production. A third case checks that the button does not stay on "Loading replies…" when the first-load refetch replaces a request still in flight. I added the test to draft-images.config.ts and tests/tsconfig.json, so the gate runs and type-checks it.

I did not reproduce the race in a browser, because it needs two requests in flight at the same time.

#480 adds a line at the same place in draft-images.config.ts, so whichever lands second needs a one-line rebase.

🤖 Generated with Claude Code

[xHeaven]

Closing this as already implemented (multiple times).