MAX_MESSAGES_AFTER_LOADING = 2000 is the ceiling for the conversation being
read - it exists so that jumping to a pinned message is not thrown away by the
next person to speak. appendMessage applied it to every buffer, and
nothing ever released a conversation once you had left it.
This window is subscribed to 485 buffers. Counted from the daemon's own store,
38 of them took traffic in the last twelve hours, 35,878 messages between
them - of which the renderer was holding 20,622, none of them drawn, and
all of them already written to SQLite on the way in.
The solution
The generous ceiling is for the buffer on screen. Everything else keeps MAX_MESSAGES_IDLE = 200 - enough to fill the screen the instant it is opened
again - applied both as messages arrive and as a trim of the conversation
being left, at the moment its size stops being anybody's business.
Nothing is lost by it. Every message was persisted as it arrived, and the
paging that already serves scrolling upwards is what brings the rest back. The
cost is one fetch if somebody goes back to where they were, which is the fetch
they would have made had they never been there.
Result
Over the same twelve-hour window: 20,622 messages held, now 3,224.
Fixed in 46e3d7f "Draw the part of the log somebody is reading".
## The problem
`MAX_MESSAGES_AFTER_LOADING = 2000` is the ceiling for the conversation being
read - it exists so that jumping to a pinned message is not thrown away by the
next person to speak. `appendMessage` applied it to **every** buffer, and
nothing ever released a conversation once you had left it.
This window is subscribed to 485 buffers. Counted from the daemon's own store,
38 of them took traffic in the last twelve hours, 35,878 messages between
them - of which the renderer was holding **20,622**, none of them drawn, and
all of them already written to SQLite on the way in.
## The solution
The generous ceiling is for the buffer on screen. Everything else keeps
`MAX_MESSAGES_IDLE = 200` - enough to fill the screen the instant it is opened
again - applied both as messages arrive and as a trim of the conversation
being left, at the moment its size stops being anybody's business.
Nothing is lost by it. Every message was persisted as it arrived, and the
paging that already serves scrolling upwards is what brings the rest back. The
cost is one fetch if somebody goes back to where they were, which is the fetch
they would have made had they never been there.
## Result
Over the same twelve-hour window: **20,622 messages held, now 3,224**.
Fixed in 46e3d7f "Draw the part of the log somebody is reading".
Salastil
added the bug label 2026-09-07 17:52:34 -04:00
Measured over the same twelve-hour window that prompted the report: 20,622 messages held across 38 buffers, now 3,224.
Finished - https://git.salastil.com/Salastil/moho/commit/46e3d7f9530fcb1f46fbcb2fad0260110d78b2a6
Measured over the same twelve-hour window that prompted the report: 20,622 messages held across 38 buffers, now 3,224.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The problem
MAX_MESSAGES_AFTER_LOADING = 2000is the ceiling for the conversation beingread - it exists so that jumping to a pinned message is not thrown away by the
next person to speak.
appendMessageapplied it to every buffer, andnothing ever released a conversation once you had left it.
This window is subscribed to 485 buffers. Counted from the daemon's own store,
38 of them took traffic in the last twelve hours, 35,878 messages between
them - of which the renderer was holding 20,622, none of them drawn, and
all of them already written to SQLite on the way in.
The solution
The generous ceiling is for the buffer on screen. Everything else keeps
MAX_MESSAGES_IDLE = 200- enough to fill the screen the instant it is openedagain - applied both as messages arrive and as a trim of the conversation
being left, at the moment its size stops being anybody's business.
Nothing is lost by it. Every message was persisted as it arrived, and the
paging that already serves scrolling upwards is what brings the rest back. The
cost is one fetch if somebody goes back to where they were, which is the fetch
they would have made had they never been there.
Result
Over the same twelve-hour window: 20,622 messages held, now 3,224.
Fixed in
46e3d7f"Draw the part of the log somebody is reading".Finished -
46e3d7f953Measured over the same twelve-hour window that prompted the report: 20,622 messages held across 38 buffers, now 3,224.