Threads and replies

[martinmitrevski]

Threads were modelled on the read path only. MessageDto carried ParentId, ReplyCount, bShowInChannel and ThreadParticipants, but MessageRequestDto had // TODO ParentId, bShowInChannel and both MessageStore and ChannelState had // TODO Threads. Nothing could be replied to, so the read path had nothing to read.

Two commits, split the way attachments landed in #153 and #154: the SDK, then the sample UI.

SDK

The write path is ParentId + bShowInChannel on the request DTO, sent by FMessage::ToRequestDto. Alongside it, three endpoints — GetReplies, QueryThreads, GetThread — with DTOs under Request/Thread and Response/Thread.

FMessageStore keeps a thread's replies keyed by parent ID and out of the channel message list unless the reply was sent with show_in_channel. That is what the backend reports too: querying channel state returns the channel's history, not its threads, so storing them together is what would otherwise interleave a thread into the conversation. A reply visible in both lists is one shared FMessage, so an edit or reaction through either is seen by both, and a new reply bumps its parent's ReplyCount without a refetch.

UChatChannel gains SendReply, QueryReplies, QueryAdditionalReplies, GetReplies and RepliesUpdated. The thread-list surface is UStreamChatClientComponent::QueryThreads, returning FChatThread — named around the engine's own FThread in HAL/Thread.h — with FThreadSortOption.

Typing events already carried ParentId and led nowhere; OnThreadTypingIndicator now carries it, and OnTypingIndicator still fires for everything, so nothing existing changes.

Two API behaviours worth knowing

Both found by probing the live API rather than trusting the docs, and both pinned by tests because both fail silently:

• A reply comes back as type regular, not reply, despite EMessageTypeDto::Reply existing and the docs saying otherwise. So a reply is identified by its parent: IsThreadReply() goes by ParentId, and SendReply leaves Type alone rather than making the optimistic copy disagree with the socket echo.
• GET /threads/{message_id} returns no participants at all unless participant_limit is passed. Exposed at the client level so ThreadParticipants is not silently empty.

Sample UI

On a phone there was no way to reach message actions or reactions — both hang off UMessageHoverMenuWidget, created in NativeOnMouseEnter, and a touch screen has no mouse-enter. Long pressing a message now opens one sheet with the reaction picker above the action list, so replying in a thread, reacting, copying and editing are reachable on iOS for the first time. Hover is untouched, so desktop keeps the bar it always had.

The gesture does not fight scrolling: NativeOnMouseButtonDown returns unhandled so the list still gets the press for a scroll drag. Once the list takes the pointer no move or up event reaches the message, so instead the message's own position is compared against where it sat at press time — if the list scrolled, the message moved, and it was not a long press.

No .uasset in this change. The picker and action-list classes are read off the hover menu's defaults (the native classes have no widget tree and would render blank), the picker rides at the top of the action sheet via a new SetHeaderContent, and UThreadReplyContextMenuAction is inserted in C++ because WBP_ContextMenu predates threads — the same reasoning as the composer's attach button.

Under a message only a reply count remains, and only when there is one; starting a thread is an action.

One deliberate behaviour change

A reply arriving over the socket no longer appears inline in the channel message list unless show_in_channel is set. That matches what the server returns in channel state — previously such replies showed up live and then vanished on reload.

Verification

	strict build (-NoPCH -NoSharedPCH -DisableUnity)	tests
UE 5.7	0 errors, 0 warnings	59/59
UE 5.8.1	0 errors, 0 warnings	59/59

New tests: eleven offline FMessageStore specs (reply routing, show_in_channel in both lists, reply-count accounting, the store merge channel pagination performs), a live ChatApi.Thread block exercising all three endpoints, and the thread wire keys pinned in the naming-convention spec — a wrong key for parent_id is accepted as a plain channel message rather than rejected.

Also packaged, installed and run on an iPhone 15 Pro (iOS 26.5), confirmed connected to Stream from the server side. Two bugs only a device would have surfaced were fixed on the way: the thread footer was built in OnSetup, before the list view parents the widget, so GetTheme() would have tripped its bConstructed ensure; and GetPosition asked the store for the next message, which for a thread's parent answers with the next channel message and costs the parent its timestamp and avatar.

Not included

The queryThreads UI (a thread-list screen, as iOS has with ChatThreadListVC). The SDK surface for it is here; the screen is not.

🤖 Generated with Claude Code