Repository navigation
fix(chat): keep the reply count of a thread up to date - #7034
AndyScherzinger wants to merge 2 commits into
Conversation
📱 QA build
The QA build installs alongside a released Nextcloud app, so you can keep Downloading the file requires a GitHub account, so open this link on the |
|
Thank you Andy 👍 , iirc i implemented the counting locally and afterwards it was implemented that the server returns it. |
|
Happy to help @mahibi - we can go either way. Currently it is broken, since it is cached in the DB but never updated, so it turns stale after initial save... So could go in as is and either stay or be replaced later on with local counting, whatever you prefer |
|
/backport to stable-25.1.x |
|
I remembered that with removing the local solution some more code should be able to be removed. Claude confirms (but i did not verify yet): The local reply counting from #(show number of thread replies, 0d919a5) is now fully superseded by the server-provided counts, and its remaining pieces are already dead code on master. The view holders and the ChatViewModel wrapper that called it were removed during the Compose/ExoPlayer migration, so nothing calls it anymore. This PR seems like a good place to remove the rest: ChatMessagesDao.getNumberOfThreadReplies(...), the SELECT COUNT(*) query There are no other references in main, test or androidTest. Optional: OfflineFirstChatRepository.updateThreadReplies runs one UPDATE per thread, up to 50. Moving that loop into a @transaction method on the DAO, the same way upsertChatMessagesAndDeleteTemp works, would batch it into a single transaction and a single Room invalidation. |
27e90f4 to
c4c9236
Compare
The "x replies" label of a thread root is read from the cached root message, which only changed when the root message itself was fetched again. The server sends the current reply count of the thread with every message of the thread, over the chat API and the chat relay alike, but it was only stored on the reply itself. Replies fetched by the background prefetch or while the chat was open therefore never reached the label. When messages are stored, copy the reply count of the newest message of each thread onto the cached root message. Every sync path stores messages through upsertChatMessagesAndDeleteTemp, so HTTP polling, signaling and the background prefetch are all covered. Counts that are already stale in the cache are not touched by that, as no new message of the thread may arrive. Opening the main chat therefore also fetches the recently active threads of the conversation and writes their reply counts into the cached roots, the way the web client takes them from its thread list. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
The reply count of a thread is taken from the server, so the local count of replies by parent message is no longer used anywhere. Remove the query and its repository and preview wrappers. Assisted-by: Claude Code:claude-opus-5-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
c4c9236 to
d450b54
Compare
|
@mahibi thanks, both done and pushed:
The branch is rebased onto current master; the thread tests and |
The "x replies" button of a thread in a conversation showed a stale reply count (e.g. 7 instead of 23), while the server and the web client had the correct one.
The count is taken from the cached root message of the thread, and that row only changed when the root message itself was fetched again. The server sends the thread's current reply count with every message of the thread (chat API and chat relay alike), but it was only stored on the reply itself. Replies fetched by the background prefetch or while the chat was open therefore never reached the button, even though opening the thread showed all of them.
This PR fixes it in two places:
ChatMessagesDao.upsertChatMessagesAndDeleteTemp, the path of HTTP polling, signaling and the background prefetch), the reply count of the newest message of each thread is copied onto the cached root message.threads/recent, limited to the server maximum of 50) and writes their reply counts into the cached roots, the way the web client takes them from its thread list. It only runs when the server has thethreadscapability.In the long run we might want to move the thread count refresh over to the insurance request cycle (
INSURANCE_REQUEST_DELAYinOfflineFirstChatRepository.kt), but for a swift cleanup it might be worth keeping it as done in this PR.Verified on a device against cloud.nextcloud.com: the thread that showed 7 replies shows 23 after opening the chat.
🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)