fix: ui does not update after pruning only files

[abhinavkrin]

Proposed changes (including videos or screenshots)

This PR resolves a regression where the UI fails to update reactively after pruning only files using the “Prune messages” feature. Users must currently reload the page manually to see the deleted files disappear, a behavior that deviates from version 7.6.0, where the UI responded automatically.

The issue is caused from the lack of an explicit broadcast when filesOnly is true—unlike full message pruning, which uses the deleteMessageBulk event to notify clients. To address this, a new deleteFilesBulk event has been added to handle these cases and ensure client-side updates.

A contributing factor to this regression was a recent change that disables DB watchers by default in production environments. This change, most probably, prevented sending stream-room-messages event automatically (due to absense of explicit broadcast)

Together, these adjustments restore reactive file pruning functionality and improve consistency between environments and versions.

Issue(s)

Steps to test or reproduce

1. Go to a channel.
2. Send an image to the channel.
3. Open “Prune messages”.
4. Set “Newer than” to the current date.
5. Select “Only remove the attached files, keep messages”.
6. Confirm and execute the action.
7. Observe the UI now updates without requiring a reload.

Further comments

CORE-1168

UPDATE

• Instead of a new event, extended the existing deleteMessageBulk event to cover filesOnly pruning cases.

[dionisio-bot]

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: 95a52f9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 36 packages

Name	Type
@rocket.chat/core-services	Patch
@rocket.chat/ddp-client	Patch
@rocket.chat/meteor	Patch
@rocket.chat/account-service	Patch
@rocket.chat/authorization-service	Patch
@rocket.chat/ddp-streamer	Patch
@rocket.chat/omnichannel-transcript	Patch
@rocket.chat/presence-service	Patch
@rocket.chat/queue-worker	Patch
@rocket.chat/stream-hub-service	Patch
@rocket.chat/network-broker	Patch
@rocket.chat/omnichannel-services	Patch
@rocket.chat/presence	Patch
rocketchat-services	Patch
@rocket.chat/livechat	Patch
@rocket.chat/mock-providers	Patch
@rocket.chat/ui-contexts	Patch
@rocket.chat/uikit-playground	Patch
@rocket.chat/fuselage-ui-kit	Patch
@rocket.chat/gazzodown	Patch
@rocket.chat/ui-avatar	Patch
@rocket.chat/ui-client	Patch
@rocket.chat/ui-video-conf	Patch
@rocket.chat/ui-voip	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/rest-typings	Patch
@rocket.chat/api-client	Patch
@rocket.chat/apps	Patch
@rocket.chat/cron	Patch
@rocket.chat/freeswitch	Patch
@rocket.chat/http-router	Patch
@rocket.chat/model-typings	Patch
@rocket.chat/license	Patch
@rocket.chat/pdf-worker	Patch
@rocket.chat/models	Patch
@rocket.chat/instance-status	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://RocketChat.github.io/Rocket.Chat/pr-preview/pr-36099/
Built to branch gh-pages at 2025-07-16 18:28 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[codecov]

Codecov Report

Attention: Patch coverage is 64.19753% with 29 lines in your changes missing coverage. Please review.

Project coverage is 65.52%. Comparing base (d7d9a8c) to head (95a52f9).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #36099      +/-   ##
===========================================
+ Coverage    65.50%   65.52%   +0.01%     
===========================================
  Files         3168     3169       +1     
  Lines       105117   105177      +60     
  Branches     20021    20030       +9     
===========================================
+ Hits         68858    68918      +60     
- Misses       33579    33581       +2     
+ Partials      2680     2678       -2     

Flag	Coverage Δ
e2e	58.23% <34.88%> (+0.02%)	⬆️
unit	70.62% <80.39%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ggazzo]

do you know when this regression was introduced?
I'm finding a lot of changes for a regression and too much to solve this problem

[gabriellsh]

I noticed that this behavior changes based on dbWatchersDisabled. If set to false, the file pruning is reactive, set to true, it stops working. Recently this flag was changed from default false to default true (which could be the reason for the regression). For the CI, the flag is still set to false, this means that the implemented e2e tests would pass even without the fix (not really testing the fix).

[gabriellsh]

I noticed that this behavior changes based on dbWatchersDisabled. If set to false, the file pruning is reactive, set to true, it stops working. Recently this flag was changed from default false to default true (which could be the reason for the regression). For the CI, the flag is still set to false, this means that the implemented e2e tests would pass even without the fix (not really testing the fix).

Retification: The flag was also inverted in the CI, you can just disregard this comment

[abhinavkrin]

do you know when this regression was introduced? I'm finding a lot of changes for a regression and too much to solve this problem

Hey, @ggazzo , After debugging this, we identified a two-step root cause:

1. The filesOnly path in cleanRoomHistory was never designed to broadcast any events for reactivity. It silently relied on DB watchers to pick up the changes. So technically, this wasn't a regression in logic—it was a missing feature all along.

2. This gap was only surfaced recently when DB watchers were disabled by default in production via PR #35981. Prior to that, the watchers filled in the gap and made the UI appear reactive, masking the problem.

So while this behavior has likely existed for a long time, the regression (as experienced by users) was triggered when we disabled DB watchers by default. We’re fixing it now by explicitly adding a deleteFilesBulk event broadcast to ensure proper reactivity regardless of watcher settings.

Hope this clarifies the context!

[ggazzo]

why not use deleteMessageBulk and avoid one extra stream for the same action? to not mention the number of changes

[CLAassistant]

All committers have signed the CLA.

[abhinavkrin]

why not use deleteMessageBulk and avoid one extra stream for the same action? to not mention the number of changes

Instead of introducing a new event, I have modified the original deleteMessageBulk event to handle cases for filesOnly pruning.

[kodiakhq]

This PR currently has a merge conflict. Please resolve this and then re-add the ['stat: ready to merge', 'automerge'] label.