Opening a 1:1 chat from Chats can show an empty conversation until Info → Back #25
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Opening a 1:1 chat from Chats can show an empty conversation until Info → Back
Build: TestFlight 1.1.0 (96)
Related: #11
Summary
Opening an existing 1:1 conversation from the normal Chats list can show an empty timeline, an incorrect contact state, and an unlocked encryption icon, even though the conversation history exists locally.
Opening Info and returning to the conversation causes the history and the expected encryption state to appear.
The same conversation opens correctly through Contacts and JID search in Chats.
Environment
Device B: iPhone 17 Pro Max, iOS 27.0.1, build 95 → 96 over existing data
Account: testman435@another.im
Peer: testman421@another.im
The conversation already contained history and media attachments. The chat row displayed the latest message preview, “Photo”, before opening it.
Steps to reproduce
Open Chats with an empty search field.
In the normal chat list, tap an existing conversation with message history.
Check the message timeline and header state.
Tap the peer name → open Info.
Return to the conversation.
Compare the result with opening the same peer through Contacts or JID search.
Actual result
On the first open from the normal Chats row:
the timeline is empty;
“Not in your contacts” is shown;
the lock icon is open.
However, Info confirms that the conversation's media and OMEMO state exist.
After Info → Back:
the expected message history appears;
the lock is closed;
“New keys to review” is displayed.
The same history is available when opening the conversation through Contacts or JID search.
Diagnostics
Multiple diagnostics exports show history responses being received after their request tokens are no longer present in pending, resulting in “reply to an unknown token” warnings.
In one documented build 96 case:
initial history request: token 882;
two milliseconds later, the response was discarded as an unknown token;
after returning from Info, a new history request was registered with token 981;
no unknown-token warning was recorded for token 981, and the history was visible afterward.
TackyBackend.resolve discards responses whose tokens are no longer in pending. TackyBackend.cancel removes pending requests without logging the cancellation reason.
Investigation direction
The evidence suggests that the initial conversation-loading task may be cancelled when opening the chat from the normal Chats list.
The current diagnostics do not establish what removed the initial history token from pending.
Please correlate:
the conversation screen instance;
the start and cancellation of ConversationModel.run();
the removal of the history request token from pending.
Retest criteria
After cold launches, opening an existing conversation through the normal Chats list, search, and Contacts should immediately show the same existing history and contact/encryption state.
The history must remain visible after Info → Back.
Fixed in branch
fix/app-issues-25-28(https://dev.another.im/another-im/anotherim-swift/compare/master...fix/app-issues-25-28), commitfe1bacf0:ConversationModel.runloaded the header, the draft and the first page inside the screen's.task; when that task was cancelled as the screen settled, the live header (roster and OMEMO read withtry?) came back as a stranger's with an open lock, and the first page's cancellation was dropped with nothing asking again, which is the "reply to an unknown token" in the diagnostics. Info → Back ran the task anew. The loads now run in tasks of their own; only following the chat's events ends with the screen. What cancels the task on the Chats path is not established (likely the screen rebuilt while the chat list changes on open); TackyBackend now logs "request cancelled by its task" (debug) with module, method and token, so a new export shows it. Test: ConversationModelTests.aRunCancelledAtOnceStillLoads.[iOS · Conversation · 1:1] Open chat does not show new incoming or outgoing messages until reopened
Build: TestFlight 1.1.0 (98), also reproduced on build 97. Date: 09 Nov 2026. Severity: Blocker. Status: Reproduced; the event-handling mechanism is identified, but the reason the conversation view disappears immediately after opening is still unknown.
Related ticket: #25. The fix in commit
fe1bacf0is a likely regression source. Вставленный MarkdownEnvironment
A: iPhone 13 Pro Max, iOS 26.7.1, build 98, testman421@another.im
B: iPhone 17 Pro Max, iOS 27.0.1, build 97, testman435@another.im
Production another.im server, 1:1 OMEMO chat.
Builds 97 and 98 contain
fe1bacf0; build 96 does not. Вставленный MarkdownSteps to reproduce
Open a 1:1 chat and keep it open.
Send one or more messages from the other device.
Observe the open conversation.
Also send a message from the device with the open conversation.
Leave the chat and open it again.
Expected result
New incoming and outgoing messages appear in the open transcript immediately. Displayed incoming messages are marked as read.
Actual result
While the chat is open:
New incoming messages do not appear.
The sender's own newly sent messages may also not appear.
The unread counter increases for incoming messages.
After leaving and reopening the chat, the missing messages become visible.
The issue was observed in both directions and reproduced 2/2 according to the tester.
Diagnostics and suspected mechanism
The build 97 log shows chat_state inactive immediately on every documented chat opening, before the initial history request. Since ConversationModel.close() is the only application path sending this state, this indicates that the conversation view's onDisappear is triggered during opening. Вставленный Markdown
After commit
fe1bacf0, initial header/history loading runs in separate tasks, while the live for await event in events loop remains tied to the screen task. If the screen task is cancelled, history can still load, but live New, Confirmed, and Status events no longer reach the transcript. This matches the observed behavior: backend events are logged, but the open UI does not update. Вставленный MarkdownThe underlying reason why the conversation view disappears/recreates immediately after opening has not been established.
Retest criteria
Opening a chat does not trigger chat_state inactive before the initial history request.
Five consecutive incoming messages all appear immediately in an open chat.
Outgoing messages appear immediately and their status updates without reopening.
The unread counter does not increase for messages already visible in the open chat.
Initial header and history loading from the #25 fix continue to work.
Verify both directions and after backgrounding/foregrounding the app with the chat open.
[iOS · Conversation · Read State] Unread count is not cleared after viewing messages because no read marker is sent
Build: TestFlight 1.1.0 (97); build 98 observed by the tester.
Date: November 9, 2026
Severity: Major
Status: Observed; root cause not yet established.
Summary
After incoming messages are displayed in a conversation, the unread counter remains unchanged. Diagnostics show that the app does not send message mark_own_read or message mark_displayed after the chat is reopened.
This may be related to BUG_98_open_chat_stops_showing_new_messages, but the relationship has not been established and is tracked separately.
Environment
Sender (A): iPhone 13 Pro Max, iOS 26.7.1, build 98
Recipient (B): iPhone 17 Pro Max, iOS 27.0.1, build 97
Server: production another.im
1:1 OMEMO chat
Steps to reproduce
On B, receive several incoming messages while the chat is not being read.
Verify that the chat list shows an unread count (6 in the documented run).
Open the conversation and wait until the messages are displayed.
Return to the chat list.
Check the conversation and total unread counters.
Expected result
Once incoming messages have been displayed in the open conversation:
the messages are marked as read;
the conversation unread counter is cleared;
the total unread counter is updated;
a read/displayed marker is sent to the sender when read receipts are enabled.
Actual result
The tester observed that the unread count remained unchanged after reopening the chat and viewing all six messages.
In the recipient diagnostics:
six incoming messages were recorded between 16:44:26 and 16:44:37 UTC;
the chat list reported unread: 6;
the conversation was reopened at 16:46:10 UTC and history loading started;
no message mark_own_read or message mark_displayed command was recorded before the end of the export at 16:46:34 UTC.
No such commands were found anywhere in the captured log.
Code observation
In build 98 sources, the read-state flow is:
visible transcript rows → markSeen → ConversationModel.saw → markRead → mark_own_read and, for 1:1 chats, mark_displayed.
The available log does not show where this chain stops. Possible causes include:
the messages not being reported as visible;
scenePhase not being .active;
markedRead already being ahead of the message keys due to the own_read state returned during loading.
Root cause is not established.
Retest criteria
In a clean scenario, send messages while the conversation is closed on B.
Open the conversation and confirm that the messages are visible.
Verify that the unread count is cleared and the total unread count is updated.
Verify mark_own_read and mark_displayed in diagnostics for the latest visible incoming message.
Confirm that the sender receives the expected read status and that the unread count does not return after an app restart.
A clean 2/2 reproduction with additional diagnostics, including the own_read response and saw calls, is recommended to identify the failing step.