- Ya
- 28 Agosti 2026, 01:24 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 0d96bb9
Two costs, both paid on every single open of a chat window. ?since on GET /sessions/{guid}/messages. A window being reopened wants the messages after the one it already holds, and had no way to say so — the only question this endpoint answered was "the newest page", which is right the first time and wrong every time after. So each reopen re-read a hundred rows, ran a translation pass over them, queried their reactions and wrote an audit row per inclusive: two messages can share a millisecond, a strictly-greater cut would drop the second of them permanently, and the client already dedupes by id because a page that races a send returns overlapping rows anyway. Absent or unparseable, the behaviour is exactly what it was, so an older client loses The query lives in MediaService rather than beside the other MediaObj queries: the shared library ships as one pinned version to the whole fleet, and this is one endpoint's read. Its fetch joins mirror the opening page's exactly, INNER join to member included — the catch-up must return the same rows that page would have, and widening it here would make member-less objects appear on reopen and nowhere else. A FULL page back from a catch-up is the client's signal that more arrived than one page holds and the rows it did not get are the ones in the middle; that is when it re-reads the thread instead of appending over a hole. ChatMessageAccessAuditor now records a page with recordAll instead of a loop of single saves. §164.312(b) is unchanged — still one row per message, because "was THIS message disclosed" is still the question — but a hundred-message page is one unit of work rather than a hundred, which the library's own measurement puts at 0.49 ms/row against 16.36. hibernate.jdbc.batch_size is the rest of it: the single transaction still issued an INSERT round trip per row without it, and PhiAccessLog's UUID id is assigned before the flush so these rows can batch at all. The batch is atomic, so a page is now audited completely or not at all rather than up to whichever row threw. Checked against prod before touching this: 3,094 CHAT_MESSAGE/LIST rows are present, so the trail was being written and this is a speed fix, not a repair.