fix: re-fetch message inside the write in getThreadName - #7557
fix: re-fetch message inside the write in getThreadName#7557OtavioStasiak wants to merge 1 commit into
Conversation
Walkthrough
ChangesThread name race-condition fix
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
app/lib/methods/getThreadName.test.ts (1)
47-61: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a fixture interface and an explicit helper return type.
buildMessageRecordhas no return type. Define aMessageRecordFixtureinterface and declarebuildMessageRecord(id: string): MessageRecordFixture. This keeps the fixture contract checked when the mocked update behavior changes.As per coding guidelines, “add explicit type annotations to function parameters and return types” and “prefer interfaces over type aliases for defining object shapes in TypeScript”.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/lib/methods/getThreadName.test.ts` around lines 47 - 61, Define a MessageRecordFixture interface for the fixture object, then update buildMessageRecord to explicitly return MessageRecordFixture while retaining its existing id, tmsg, stale, and prepareUpdate members and behavior.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/lib/methods/getThreadName.test.ts`:
- Around line 77-102: Strengthen the test around getThreadName by tracking when
the mocked db.write callback is active, then record whether each
mockedGetMessageById call occurs within that callback. Assert that the second
lookup happens while db.write is active, ensuring the re-fetch immediately
precedes the write rather than merely occurring after the network/decryption
work.
In `@app/lib/methods/getThreadName.ts`:
- Around line 37-44: Update the queued writer around getMessageById and the
thread prepareCreate to re-fetch getThreadById(tmid) after the writer begins;
only prepare the thread creation when that lookup still returns null. Keep the
existing create data and message update behavior unchanged, while preventing
duplicate creation when concurrent callers both passed the earlier check.
---
Nitpick comments:
In `@app/lib/methods/getThreadName.test.ts`:
- Around line 47-61: Define a MessageRecordFixture interface for the fixture
object, then update buildMessageRecord to explicitly return MessageRecordFixture
while retaining its existing id, tmsg, stale, and prepareUpdate members and
behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9da091ca-d936-4f3c-96c9-405ec33b57be
📒 Files selected for processing (2)
app/lib/methods/getThreadName.test.tsapp/lib/methods/getThreadName.ts
📜 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/lib/methods/getThreadName.test.tsapp/lib/methods/getThreadName.ts
**/*.{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/lib/methods/getThreadName.test.tsapp/lib/methods/getThreadName.ts
**/*.{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/lib/methods/getThreadName.test.tsapp/lib/methods/getThreadName.ts
🧠 Learnings (2)
📚 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/lib/methods/getThreadName.test.tsapp/lib/methods/getThreadName.ts
📚 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/lib/methods/getThreadName.test.ts
GitHub Actions
Waiting
GitHub Actions
Waiting
2 participants
Proposed changes
In
getThreadName, the "no thread yet" branch prepared its update on a message record fetched before the network call and decryption. A sync write can update or delete that row during the gap, makingprepareUpdatethrow on a record with pending changes.The message is now re-fetched inside the
db.writecallback, and the update is prepared on that fresh record.getSingleMessageandEncryption.decryptMessagestay outside the lock, and the function signature and callers are unchanged.Added a regression test that mocks
database.activeand simulates a concurrent writer during the gap, the function still commits without throwing.Issue(s)
https://rocketchat.atlassian.net/browse/NATIVE-1469
How to test or reproduce
TZ=UTC npx jest app/lib/methods/getThreadName.test.ts— passes on this branch.app/lib/methods/getThreadName.tsand re-run — the test fails, showing the update was prepared on the stale record.reply after a fresh cache clear) while messages are syncing. The thread name should resolve and no "Cannot update a record with pending changes"
error should be logged.
Screenshots
Types of changes
Checklist
Further comments
Summary by CodeRabbit
Bug Fixes
Tests