What happened
After sending a second question in a Desktop session that already contained a completed first question and answer, I observed inconsistent message visibility:
- The second question was not visible, although the thinking/running indicator was still displayed.
- The second answer began streaming, but some content that had already been displayed later became invisible.
- After switching to another session and back several times, only the second question and answer were visible. The first question and answer were absent from the current message list.
This describes the observed symptoms. No screen recording is available, so the exact sequence of display changes and scroll positions cannot be reconstructed reliably.
A subsequent read-only examination of SQLite confirmed that all 233 persisted records across both turns were still present. No deletion of those persisted records was found.
Expected behavior: Submitted questions and streaming answers should display normally. Older content may be paginated, but loading earlier history should make it accessible. Background message updates should not repeatedly replace the current reading range with a different turn.
How to reproduce
The incident occurred under the following conditions:
- Complete a first turn in a Desktop session. In the affected session, this turn contained large tool results, and its fully decoded message data exceeded 512 KiB.
- Submit a second question in the same session and allow the answer to stream.
- Observe the message list during generation, then switch to another session and back. The visibility problems described above occurred during this workflow.
The frequency of reproduction through these UI steps has not been measured. The reading-anchor state at the time of the incident was not captured, so these steps are not claimed to reproduce the problem on every attempt.
During diagnosis, the old version’s actual paging, cache, and reading-position restoration logic was replayed against the affected session’s persisted data. With an explicit saved reading anchor pointing to the first turn, the replay reproduced the two turns repeatedly replacing each other in the resident message range.
A separate code-level reproduction also confirmed that loading earlier history from the second turn reads the first turn and then immediately evicts it, leaving the resident range unchanged. This is a verified paging defect; it is not a claim that upward scrolling was attempted during the original incident.
Environment
- Maka: 0.2.0, development build, commit
c180a2b, as recorded in the affected instance’s logs.
- OS: macOS 14.2.1; application process architecture: x64.
- Surface: Desktop.
- Electron: 43.4.1.
- Node.js: 24.18.1, as recorded in the running instance’s logs.
Logs, screenshots, or additional context
Read-only inspection of the persisted transcript found:
| Turn |
Durable sequence range |
Record count |
Fully decoded data size |
| First turn |
0–194 |
195 |
1,684,360 bytes, approximately 1.61 MiB |
| Second turn |
195–232 |
38 |
95,288 bytes, approximately 93.1 KiB |
These sizes measure the UTF-8 JSON representation of the complete records, including tool calls and tool results. They are not the sizes of the visible answer text. Tool results stored in chunks were reassembled before measuring.
The old Desktop code uses a 512 KiB resident-message budget and evicts whole turns. A protected turn may exceed this soft budget.
The reading-position restoration effect depends on messages, allowing subsequent message updates to restore an old anchor again after an earlier restoration has completed. Meanwhile, background durable catch-up moves a range that is behind the tail back to the latest turn. These two loading policies can therefore protect different turns and evict each other’s content from the resident range.
The following is a diagnostic replay summary, not a recording of the original UI events. A and B represent the first and second turns. Sequence numbers are zero-based.
Load A resident=0–194
Persist B's question and initial state resident=195–196
Restore the saved reading anchor in A resident=0–194
Persist subsequent records from B resident=195–204
Restore the saved anchor in A again resident=0–194
Return to the latest range resident=195–204
loadBefore(195, 128 KiB) resident=195–204, hasOlder=true
The final operation reads A but still leaves only B resident, demonstrating that loading earlier history makes no progress.
Logs from the same period also contain five automatic subscription recoveries with:
[2026-09-07T04:50:36.764Z] WARN [runtime-host-session-observer] recovering subscription {
sessionId: '<redacted-id>',
turnId: '<redacted-id>',
runId: '<redacted-id>',
reason: 'subscription_closed',
message: 'Session subscription was not found'
}
[2026-09-07T04:50:37.006Z] INFO [runtime-host-session-observer] subscription recovered {
sessionId: '<redacted-id>',
turnId: '<redacted-id>',
runId: '<redacted-id>',
reason: 'subscription_closed',
message: 'Session subscription was not found'
}
Those logs do not record why the subscriptions were initially closed. They are supplementary context and do not establish that subscription recovery was the root cause or a necessary trigger for the visibility defect.
The first screenshot shows that after I submitted the second question, it was not visible in the conversation.
The second screenshot shows that after the second answer was complete, I scrolled all the way to the top, but the first question and its answer were still not visible.
What happened
After sending a second question in a Desktop session that already contained a completed first question and answer, I observed inconsistent message visibility:
This describes the observed symptoms. No screen recording is available, so the exact sequence of display changes and scroll positions cannot be reconstructed reliably.
A subsequent read-only examination of SQLite confirmed that all 233 persisted records across both turns were still present. No deletion of those persisted records was found.
Expected behavior: Submitted questions and streaming answers should display normally. Older content may be paginated, but loading earlier history should make it accessible. Background message updates should not repeatedly replace the current reading range with a different turn.
How to reproduce
The incident occurred under the following conditions:
The frequency of reproduction through these UI steps has not been measured. The reading-anchor state at the time of the incident was not captured, so these steps are not claimed to reproduce the problem on every attempt.
During diagnosis, the old version’s actual paging, cache, and reading-position restoration logic was replayed against the affected session’s persisted data. With an explicit saved reading anchor pointing to the first turn, the replay reproduced the two turns repeatedly replacing each other in the resident message range.
A separate code-level reproduction also confirmed that loading earlier history from the second turn reads the first turn and then immediately evicts it, leaving the resident range unchanged. This is a verified paging defect; it is not a claim that upward scrolling was attempted during the original incident.
Environment
c180a2b, as recorded in the affected instance’s logs.Logs, screenshots, or additional context
Read-only inspection of the persisted transcript found:
These sizes measure the UTF-8 JSON representation of the complete records, including tool calls and tool results. They are not the sizes of the visible answer text. Tool results stored in chunks were reassembled before measuring.
The old Desktop code uses a 512 KiB resident-message budget and evicts whole turns. A protected turn may exceed this soft budget.
The reading-position restoration effect depends on
messages, allowing subsequent message updates to restore an old anchor again after an earlier restoration has completed. Meanwhile, background durable catch-up moves a range that is behind the tail back to the latest turn. These two loading policies can therefore protect different turns and evict each other’s content from the resident range.The following is a diagnostic replay summary, not a recording of the original UI events. A and B represent the first and second turns. Sequence numbers are zero-based.
The final operation reads A but still leaves only B resident, demonstrating that loading earlier history makes no progress.
Logs from the same period also contain five automatic subscription recoveries with:
Those logs do not record why the subscriptions were initially closed. They are supplementary context and do not establish that subscription recovery was the root cause or a necessary trigger for the visibility defect.