Skip to content

fix: allow retrying/deleting stuck (TEMP) messages - #7561

Open
deepak0x wants to merge 1 commit into
RocketChat:developfrom
deepak0x:fix/6830-stuck-message-retry-v2
Open

fix: allow retrying/deleting stuck (TEMP) messages#7561
deepak0x wants to merge 1 commit into
RocketChat:developfrom
deepak0x:fix/6830-stuck-message-retry-v2

Conversation

@deepak0x

@deepak0x deepak0x commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Proposed changes

A message stuck in the TEMP (sending) state could not be retried or deleted from the app — the only way to clear it was to wipe the app data and log back in. MessageErrorActions (resend/delete) only surfaced for ERROR status, so TEMP messages never showed the error/retry affordance.

Message.hasError only returned true for ERROR status. This extends it to also treat TEMP status as an error, so the retry/delete action sheet is available for stuck-sending messages.

Issue(s)

Fixes #6830

How to test or reproduce

  1. Send a message that gets stuck in the TEMP (sending) state (e.g. a transient send failure).
  2. Before this fix: the message shows a spinner and offers no way to retry or delete it — you must wipe app data.
  3. After this fix: the message shows the error/retry icon; tapping it opens the Resend / Delete action sheet.

Regression test added: app/containers/message/index.test.tsx asserts Message.hasError is true for TEMP (and ERROR) and false for SENT. It fails against the unfixed getter and passes after the fix (verified by running the suite locally).

Screenshots

N/A (behavior only, no visual change).

Types of changes

  • Bugfix (non-breaking change which fixes an issue)

Checklist

  • I have read the CONTRIBUTING doc
  • I have signed the CLA
  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works (if applicable)
  • I have added necessary documentation (if applicable)
  • Any dependent changes have been merged and published in downstream modules

Further comments

The reported 4.66 -> 4.67 regression (messages getting stuck) could not be reproduced by maintainers and no server/client logs were provided, so the root send failure is not addressed here. This change fixes the concrete, reproducible defect that makes a stuck message unrecoverable: it now always offers Retry / Delete, which both work regardless of the original send error.

Summary by CodeRabbit

  • Bug Fixes
    • Temporary message statuses are now correctly reported as errors, providing more accurate status information.
    • Temporary-state behavior remains unchanged.

Message component was refactored (RocketChat#7455) into a function component with the
status logic in MessageStore.useMessageStatus. hasError was only true for
ERROR status, so TEMP (stuck-sending) messages never showed the resend/delete
action sheet - the user had to wipe app data to clear them.

Extend useMessageStatus.hasError to also cover TEMP status. MessageError
already renders the retry/delete icon on hasError and triggers errorActionsShow
independently of the tappable gate, so the action sheet is now available for
stuck messages.

Update the existing useMessageStatus TEMP test to expect hasError true.

Signed-off-by: Deepak Bhagat <deepak988088@gmail.com>
@coderabbitai

coderabbitai Bot commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c48862d4-7d7b-4e90-8ccc-5e1e095d2936

📥 Commits

Reviewing files that changed from the base of the PR and between 41e87a8 and dfa62d9.

📒 Files selected for processing (2)
  • app/containers/message/stores/MessageStore.tsx
  • app/containers/message/stores/__tests__/MessageStore.test.tsx
📜 Recent review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{js,ts,jsx,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{js,ts,jsx,tsx}: Use descriptive names for functions, variables, and classes that clearly convey their purpose
Write comments that explain the 'why' behind code decisions, not the 'what'
Keep functions small and focused on a single responsibility
Use const by default, let when reassignment is needed, and avoid var
Prefer async/await over .then() chains for handling asynchronous operations
Use explicit error handling with try/catch blocks for async operations
Avoid deeply nested code; refactor complex logic into helper functions

Files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
  • app/containers/message/stores/MessageStore.tsx
**/*.{ts,tsx}

📄 CodeRabbit inference engine (AGENTS.md)

**/*.{ts,tsx}: Use TypeScript for type safety; add explicit type annotations to function parameters and return types
Prefer interfaces over type aliases for defining object shapes in TypeScript
Use enums for sets of related constants rather than magic strings or numbers

Files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
  • app/containers/message/stores/MessageStore.tsx
**/*.{js,jsx,ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{js,jsx,ts,tsx}: Format JavaScript and TypeScript code with Oxfmt using the repository configuration: tabs, single quotes, 130-character width, no trailing commas, omitted arrow-function parentheses where possible, and same-line brackets.
Follow Oxlint rules configured in .oxlintrc.json, including the import, React, Jest, TypeScript, and React Native plugins.

Files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
  • app/containers/message/stores/MessageStore.tsx
🧠 Learnings (3)
📚 Learning: 2026-04-30T17:07:51.020Z
Learnt from: diegolmello
Repo: RocketChat/Rocket.Chat.ReactNative PR: 7274
File: app/lib/services/voip/MediaCallEvents.ts:0-0
Timestamp: 2026-04-30T17:07:51.020Z
Learning: In this Rocket.Chat React Native codebase, the ESLint rule `no-void: error` is enforced. When you see a promise returned from an async call that is not awaited (a “floating promise”), do not silence it with the `void somePromise()` pattern. Instead, handle the promise explicitly by attaching `.catch(...)` (or otherwise awaiting/handling the error) so unhandled-rejection risks are addressed in a way that satisfies the existing ESLint configuration.

Applied to files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
  • app/containers/message/stores/MessageStore.tsx
📚 Learning: 2026-06-25T18:37:25.526Z
Learnt from: diegolmello
Repo: RocketChat/Rocket.Chat.ReactNative PR: 7434
File: app/views/ScreenLockConfigView.test.tsx:16-22
Timestamp: 2026-06-25T18:37:25.526Z
Learning: In Rocket.Chat ReactNative tests that mock selectors for `useAppSelector`, don’t require the mocked selector input to be typed as `IApplicationState` when the fixture only includes a partial Redux state slice (e.g., only `server` and `settings`). Requiring the full `IApplicationState` type in that scenario forces unsafe `as IApplicationState` casts and undermines type-safety. For these narrowly scoped selector-mock fixtures, use a less strict type (e.g., `any`) to keep the mock focused on the slice under test.

Applied to files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
📚 Learning: 2026-06-25T18:37:44.793Z
Learnt from: diegolmello
Repo: RocketChat/Rocket.Chat.ReactNative PR: 7434
File: app/views/ScreenLockConfigView.tsx:101-141
Timestamp: 2026-06-25T18:37:44.793Z
Learning: In the Rocket.Chat React Native codebase, do not treat passing an `async` function directly to an event prop in React/React Native UI components (e.g., `onPress={async () => ...}` in TSX) as a “floating promises” CI-blocking lint issue—this repo does not enable the ESLint `no-floating-promises` rule (while `no-void` is enforced). Only raise robustness follow-ups when there are genuinely unhandled promise paths (e.g., fire-and-forget calls like `save()` that return a Promise that is neither awaited nor handled), and prefer making sure failure paths are explicitly handled/reported rather than blocking on lint-style floating-promise concerns.

Applied to files:

  • app/containers/message/stores/__tests__/MessageStore.test.tsx
  • app/containers/message/stores/MessageStore.tsx
🔇 Additional comments (2)
app/containers/message/stores/MessageStore.tsx (1)

273-273: LGTM!

app/containers/message/stores/__tests__/MessageStore.test.tsx (1)

386-389: LGTM!


Walkthrough

useMessageStatus now reports hasError: true for TEMP messages. The related test expectation was updated. isTemp remains unchanged.

Changes

Message status handling

Layer / File(s) Summary
Temporary status error handling
app/containers/message/stores/MessageStore.tsx, app/containers/message/stores/__tests__/MessageStore.test.tsx
useMessageStatus treats TEMP messages as errors. The test verifies hasError: true while preserving temporary status behavior.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Possibly related PRs

Suggested labels: type: bug

Suggested reviewers: diegolmello

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the fix for retrying or deleting stuck TEMP messages.
Linked Issues check ✅ Passed The change treats TEMP messages as errors, restoring retry and delete actions reported in issue #6830.
Out of Scope Changes check ✅ Passed The changes are limited to TEMP message status handling and its regression test.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: Issues sending messages to normal channels as of 4.67

1 participant