StoredConversationFactory.createForParticipants(...) validates that the participants are StoredUsers and then calls createInternal(...), which constructs a StoredConversation and nothing else. No StoredSession is created.
ChatSessionRepository.createSession(...) and createSessionWithMessage(...) are the only publishers of SessionCreatedEvent (ChatSessionRepositoryImpl.kt:59 and :91), and createForParticipants calls neither.
The consequence shows up on the first message. StoredConversation.addMessageWithAwait catches the Session not found IllegalArgumentException, waits for a SessionCreatedEvent, and retries once. With no session ever created and no event ever published, that wait cannot be satisfied.
Worth being precise about the symptom: the wait is not indefinite. SessionEventAwaiter.awaitSession wraps the await in withTimeout(timeout) with a DEFAULT_TIMEOUT of 10 seconds, so the attempt fails with a TimeoutCancellationException after ~10s rather than hanging. The bug is real; the symptom is a delayed failure on the first message, not a permanent stall. Worth stating precisely since the timeout also means the failure surfaces on the async persistence path rather than to the caller of addMessage.
Question: should createForParticipants(...) create the backing session itself — it has the owner and title it needs, and createSession is idempotent-ish per session ID — or should it be documented as requiring a createSession(...) call first? The KDoc usage example currently shows createForParticipants followed directly by addMessage, which is exactly the sequence that fails.
StoredConversationFactory.createForParticipants(...)validates that the participants areStoredUsers and then callscreateInternal(...), which constructs aStoredConversationand nothing else. NoStoredSessionis created.ChatSessionRepository.createSession(...)andcreateSessionWithMessage(...)are the only publishers ofSessionCreatedEvent(ChatSessionRepositoryImpl.kt:59and:91), andcreateForParticipantscalls neither.The consequence shows up on the first message.
StoredConversation.addMessageWithAwaitcatches theSession not foundIllegalArgumentException, waits for aSessionCreatedEvent, and retries once. With no session ever created and no event ever published, that wait cannot be satisfied.Worth being precise about the symptom: the wait is not indefinite.
SessionEventAwaiter.awaitSessionwraps the await inwithTimeout(timeout)with aDEFAULT_TIMEOUTof 10 seconds, so the attempt fails with aTimeoutCancellationExceptionafter ~10s rather than hanging. The bug is real; the symptom is a delayed failure on the first message, not a permanent stall. Worth stating precisely since the timeout also means the failure surfaces on the async persistence path rather than to the caller ofaddMessage.Question: should
createForParticipants(...)create the backing session itself — it has the owner and title it needs, andcreateSessionis idempotent-ish per session ID — or should it be documented as requiring acreateSession(...)call first? The KDoc usage example currently showscreateForParticipantsfollowed directly byaddMessage, which is exactly the sequence that fails.