Are you sure that the members list of fetchThreadInfos contains all pseudo-members that need the UPDATE_THREAD? If you have visibility into a threadInfo, you need to get this update, even if you're a member. You might need to use fetchServerThreadInfos instead of fetchThreadInfos here, but I'm not 100% sure

I checked this, and I wasn't sure why I would need ServerThreadInfo when writing the code because when I introspected into both the ServerThreadInfo and RawThreadInfo and checked the member IDs, they both seemed to be identical. I'm unsure if there's a case for when the containing member IDs would be different between the two?

In regards to if we fetch the ServerThreadInfo, we could either independently fetch the RawThreadInfo at the same time to include in the return, or use a provided helper method like rawThreadInfoFromServerThreadInfo, so it should be easy enough.

This is the condition I'm concerned about. Try creating a community, adding a member, and then creating a subchannel of the community without that member. You'll probably find that member in the ServerThreadInfo for that subchannel, but NOT the RawThreadInfo

Ah you're right, ok I'll update this

Are you sure it's safe to call createUpdates before dbQuery has completed? I worry that createUpdates will fetch from the roles table, and might fetch stale content

Oh you might be right - I haven't had any issues on my dev environment but it could behave differently on larger DBs.

I should probably await the dbQuery as well before I fetch the ServerThreadInfo (in my opinion), so I can

1. dbQuery(...)
2. fetchServerThreadInfos
3. createUpdates

Yeah, that sounds right to me! Good catch