---
title: "Rocket.Chat Known Issues Guide"
slug: "known-issues"
description: "Review known issues in Rocket.Chat. Stay informed about secure communications fixes and workarounds."
updated: 2026-10-20T14:44:51Z
published: 2026-10-20T14:44:51Z
canonical: "docs.rocket.chat/known-issues"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rocket.chat/llms.txt
> Use this file to discover all available pages before exploring further.

# Known Issues

This document lists known issues identified across recent Rocket.Chat releases. These issues may affect select workspaces or deployment environments. Each item includes its current status, impact severity, affected versions, and known workarounds.

We are actively working to address these problems in upcoming patches or releases. This page will be updated as resolutions become available.

> [!NOTE]
> This table is continuously updated as new issues are discovered and addressed.

| Release | Issue Summary | Severity | Status | Introduced In | Fixed In | Workaround | Detailed Technical Guidance |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 7.4.0 to 7.9.0 | Updating a single custom field using the `users.update` endpoint in chat engine causes all other custom fields to be overwritten with blank values | Major | Resolved | 7.4.0 | 7.4.5, 7.5.4, 7.6.5, 7.7.8, 7.8.4, 7.9.1 | To prevent unintended data loss when modifying custom fields via the `users.update` endpoint, always send the full `customFields` object in the request payload including all existing custom field values—not just the specific field you're trying to update. | From version 7.4.0, when the `users.update` endpoint is called to modify a specific custom field for a user, the current implementation may not correctly merge the provided custom field data with the existing custom fields. Instead, it treats the provided payload as the complete set of custom fields for that user, overwriting any fields not explicitly included in the update request with blank values. This behavior affects Chat Engine solutions that rely on custom fields for user data. |
| 7.7.0 & 7.8.0 | Reactivity issues across multiple workspaces due to DB Watchers being disabled by default (PR #[35981](https://github.com/RocketChat/Rocket.Chat/pull/35981)) | Major | Resolved | 7.7.0 | 7.7.7 and 7.8.3 | To restore prior behavior, apply the following configuration across all deploys: ```bash DISABLE_DB_WATCHERS=false ``` > [!NOTE] > You may also use `DISABLE_DB_WATCHERS=no` — both are accepted values. | Starting in version 7.7.0, we deprecated database watchers by setting `DISABLE_DB_WATCHERS=true` as the default value. This has led to reactivity issues across some workspaces, especially those relying on oplog/change stream synchronization. Technical Context: - The environment variable `DISABLE_DB_WATCHERS` controls whether database watchers are active. - By default, this variable is now set to `true` from version 7.7.0 onward. - Reactivity issues may appear in messaging, updates, or workspace synchronization flows. > [!NOTE] > Ensure this variable is applied to all running pods/containers/services in your deployment for consistency. > [!WARNING] > This variable is deprecated in v7.7.0 and has been removed entirely in v8.0.0. Future reactivity handling will rely on an improved, scalable mechanism under development. |

If you're a premium customer experiencing any of the issues listed above, need assistance applying a workaround, or would like to report additional symptoms, reach out via our [Support Center](/v1/docs/support-center). We appreciate your patience as we resolve these issues and work to improve the platform.