Add swipe to delete for messages#97
Merged
SamanSP1386 merged 8 commits intodevfrom Apr 19, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 24 minutes and 38 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
📝 WalkthroughWalkthroughAdds comprehensive conversation and message reporting, inbox hiding, and message deletion functionality across backend and frontend, including new mutations/queries, schema updates, and swipeable UI components for managing reported content. Changes
Sequence Diagram(s)sequenceDiagram
participant User as User (Reporter)
participant UI as Frontend
participant Backend as Backend
participant DB as Database
User->>UI: Report message/conversation
UI->>UI: Open ReportModal (reason, notes)
User->>UI: Confirm report
UI->>Backend: reportMessage/reportConversation<br/>(with notes, reason)
Backend->>DB: Validate: not duplicate, rate limit ok,<br/>caller not sender/owner
DB-->>Backend: ✓ Valid
Backend->>DB: Insert report record
DB-->>Backend: reportId
Backend->>DB: Hide conversation (reason='reported')<br/>for reporter side
DB-->>Backend: ✓ Updated
Backend-->>UI: { reportId }
UI->>UI: Navigate/dismiss
Note over Backend,DB: Conversation now hidden in reporter's<br/>listUserConversations & excluded<br/>from listings search results
sequenceDiagram
participant User1 as User1 (Inbox)
participant User2 as User2 (Other)
participant UI as Frontend
participant Backend as Backend
participant DB as Database
User1->>UI: Swipe conversation left,<br/>tap "Delete"
UI->>UI: Alert confirmation
User1->>UI: Confirm
UI->>Backend: hideConversationFromInbox<br/>(reason='deleted')
Backend->>DB: Patch conversation:<br/>buyerInboxHiddenAt/Reason
DB-->>Backend: ✓ Updated
Backend-->>UI: { ok: true }
UI->>UI: Remove from inbox view
Note over User1,DB: Conversation hidden for User1 only
User2->>Backend: sendMessage to User1
Backend->>DB: Fetch conversation
DB-->>Backend: Conversation with hidden flags
Backend->>Backend: Check hidden reason,<br/>if 'deleted' preserve, else clear
Backend->>DB: Clear hidden fields if not 'reported'<br/>Update lastMessageId
DB-->>Backend: ✓ Updated
Note over Backend,DB: If reason was 'deleted',<br/>inbox stays hidden for User1.<br/>If was 'reported', clears<br/>and conversation reappears
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (5)
backend/convex/messages.ts (2)
588-623: Consider consolidating withlistings.tshelper.This query duplicates
getReportedConversationListingIdSetForViewerinbackend/convex/listings.ts(lines 67‑107). Besides DRY, there's a subtle divergence: the listings helpernormalizeIds eachtargetIdbefore looking it up, while this query casts directly — an unnormalized/foreign ID would silently propagate here but be skipped there. Extracting a single helper (or havinglistings.tscall this query's underlying function) keeps both paths in lockstep.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/convex/messages.ts` around lines 588 - 623, getReportedConversationListingIds duplicates logic from getReportedConversationListingIdSetForViewer in listings.ts; extract a shared helper (e.g., getReportedConversationListingIdsHelper) that accepts ctx and reporter userId, reuse it from both getReportedConversationListingIds and getReportedConversationListingIdSetForViewer, and ensure the helper normalizes each report.targetId via normalizeId before looking up ctx.db.get so unnormalized/foreign IDs aren't silently propagated; update both functions to call the new helper and remove the duplicated mapping/lookup logic.
920-1018:deleteMessage/reportMessageflows look correct; small nit.Authorization (
senderId === userIdfor delete,senderId !== userIdfor report), duplicate‑report guard viaby_targetindex, rate limiting, andlastMessageIdrestoration viaupdateConversationAfterDeletedMessageall look good. One nit:reportMessagepasses nosiblingConversationIdsand therefore only hides the primary conversation, whilereportConversationhides all siblings — worth a one‑line comment explaining the intentional asymmetry so future readers don't "fix" it.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/convex/messages.ts` around lines 920 - 1018, Add a one-line inline comment in the reportMessage flow (near the call to hideConversationForParticipant inside the reportMessage handler) explaining that we intentionally do not pass siblingConversationIds here and therefore only hide the primary conversation, unlike reportConversation/hideConversationFromInbox which hides siblings via siblingConversationIds; reference the functions reportMessage, reportConversation, hideConversationForParticipant, and hideConversationFromInbox and the arg siblingConversationIds so future readers understand the asymmetry is intentional.backend/convex/listings.ts (1)
67-107: Duplicated withgetReportedConversationListingIdsinmessages.ts.This helper and
backend/convex/messages.tslines 588‑623 derive the same reporter→listing‑ID set by the same algorithm (readreportsby reporter, keeptargetType === 'conversation', map throughconversations.listingId). The only difference isSetvs array and thenormalizeIdcall. Consider exporting a single shared helper (e.g. frommessages.ts) so the server query and the filtering path can't drift. Especially important because the listings helper usesnormalizeIdbut the exported query uses a raw cast — subtle behavioral inconsistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@backend/convex/listings.ts` around lines 67 - 107, These two functions duplicate the same reporter→listing-ID logic: getReportedConversationListingIdSetForViewer (in listings.ts) and getReportedConversationListingIds (in messages.ts); extract the shared behavior into a single exported helper (e.g., export getReportedConversationListingIdsShared) that performs the reports query (ctx.db.query('reports').withIndex('by_reporter', q => q.eq('reporterId', viewerId))), filters targetType === 'conversation', calls ctx.db.normalizeId('conversations', report.targetId) for each report, loads conversations with ctx.db.get, and returns a Set or array consistently; then replace both getReportedConversationListingIdSetForViewer and getReportedConversationListingIds to call that shared helper so normalization and return type are unified.frontend/app/conversations/[id].tsx (1)
41-113: Component name doesn't match behavior.
SwipeableMessageRowdoesn't implement any swipe gesture — it only wires long‑press to reveal aReportbutton. Consider renaming to e.g.MessageRowWithActions/ReportableMessageRowto avoid misleading future readers (especially given inbox uses actual swipe gestures for the same feature).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@frontend/app/conversations/`[id].tsx around lines 41 - 113, The component is misnamed—rename the function and any exports from SwipeableMessageRow to a clearer name like ReportableMessageRow (or MessageRowWithActions), keep the props and behavior unchanged, and update all import sites to use the new identifier (including story/tests/parent components that render it); also update any TypeScript types or exported names that reference SwipeableMessageRow so the build and type checks remain consistent.frontend/components/ReportModal.tsx (1)
57-97: Submit branches look correct; minor consolidation opportunity.Routing by
targetTypeis clean andtrimmedNotesis now shared. One small tweak: the same three{ reason, notes: trimmedNotes }payload shape is duplicated across branches — you could factor the call into a singleawaitper branch and keep everything else identical, e.g.:♻️ Optional refactor
- if (targetType === 'conversation') { - await reportConversation({ - conversationId: targetId as Id<'conversations'>, - reason, - notes: trimmedNotes, - }); - } else if (targetType === 'message') { - await reportMessage({ - messageId: targetId as Id<'messages'>, - reason, - notes: trimmedNotes, - }); - } else { - await createReport({ - targetId, - targetType, - reason, - notes: trimmedNotes, - }); - } + const common = { reason, notes: trimmedNotes }; + if (targetType === 'conversation') { + await reportConversation({ conversationId: targetId as Id<'conversations'>, ...common }); + } else if (targetType === 'message') { + await reportMessage({ messageId: targetId as Id<'messages'>, ...common }); + } else { + await createReport({ targetId, targetType, ...common }); + }Not blocking.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@frontend/components/ReportModal.tsx` around lines 57 - 97, The handleSubmit function has duplicated payload objects for reportConversation, reportMessage, and createReport calls with the same shape { reason, notes: trimmedNotes }. Refactor this by creating a single payload object containing reason and trimmedNotes before the if statement, then await the appropriate reporting function with this shared payload. This reduces duplication and keeps the branching logic focused only on calling the correct function based on targetType.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@backend/convex/listings.ts`:
- Around line 200-202: The current logic filters reported listings after
paginate() in searchAndFilterListings and getListings which can shrink returned
pages and leave continueCursor/isDone inconsistent; fix by detecting when
reportedConversationListingIdSet.size > 0 and route those calls into the
existing “collect up to MAX_COLLECT” post-filtering path (the branch that
gathers candidates until MAX_COLLECT before computing pagination) instead of the
fast non-post-filter branch, so you paginate over the already-filtered/collected
items (update usage around paginate(), paginationResult, and
continueCursor/isDone accordingly) — apply the same change to the other
occurrences you noted (lines around 359-368 and 473-482).
In `@backend/convex/messages.ts`:
- Around line 948-965: The handler hideConversationFromInbox currently calls
hideConversationForParticipant(..., 'deleted', now) which unconditionally
overwrites any existing hide reason; update the logic in
hideConversationFromInbox (or inside hideConversationForParticipant) to first
fetch the participant's current hidden reason and skip calling the overwrite
when that reason === 'reported' so a prior 'reported' state is preserved (ensure
the check uses the same identity for 'reported' and keep now and other args
unchanged); reference hideConversationFromInbox and
hideConversationForParticipant when locating the change and ensure
shouldPreserveHiddenConversationState semantics remain intact.
In `@frontend/app/`(tabs)/inbox.tsx:
- Around line 159-212: The pan responder can read a stale swipeStartOffset
because translateX.stopAnimation(cb) calls back asynchronously; update
onPanResponderGrant to synchronously snapshot the current animated value into
swipeStartOffset.current (e.g., read the current value from the Animated.Value
instance or maintain a mirrored ref via translateX.addListener on mount) instead
of relying only on the stopAnimation callback, so subsequent onPanResponderMove
uses the correct start offset (update references in onPanResponderGrant and
ensure the addListener teardown if you choose the listener approach).
In `@frontend/app/conversations/`[id].tsx:
- Around line 639-647: The Report action label currently forces fontSize: 8
inside the messageActionLabel style (spreading typography.footnoteMed then
overriding), which makes the uppercase label unreadable; remove the fontSize
override or change it to a readable size (around 11–12) so the style uses
typography.footnoteMed’s base size or a sensible bump, and keep other properties
(fontWeight, letterSpacing, textTransform) intact—update the messageActionLabel
definition accordingly.
- Around line 432-476: The FlatList currently sets scrollEnabled={false} which
prevents users from scrolling message history and prevents onScrollBeginDrag
from firing; remove the scrollEnabled prop from the FlatList (or change it to
scrollEnabled={activeMessageActionId === null} if you intentionally want to
disable scrolling only while an action panel is active) so that manual scrolling
and onScrollBeginDrag used to clear activeMessageActionId work correctly; look
for FlatList, scrollEnabled, activeMessageActionId, and onScrollBeginDrag in
this component to make the change.
---
Nitpick comments:
In `@backend/convex/listings.ts`:
- Around line 67-107: These two functions duplicate the same reporter→listing-ID
logic: getReportedConversationListingIdSetForViewer (in listings.ts) and
getReportedConversationListingIds (in messages.ts); extract the shared behavior
into a single exported helper (e.g., export
getReportedConversationListingIdsShared) that performs the reports query
(ctx.db.query('reports').withIndex('by_reporter', q => q.eq('reporterId',
viewerId))), filters targetType === 'conversation', calls
ctx.db.normalizeId('conversations', report.targetId) for each report, loads
conversations with ctx.db.get, and returns a Set or array consistently; then
replace both getReportedConversationListingIdSetForViewer and
getReportedConversationListingIds to call that shared helper so normalization
and return type are unified.
In `@backend/convex/messages.ts`:
- Around line 588-623: getReportedConversationListingIds duplicates logic from
getReportedConversationListingIdSetForViewer in listings.ts; extract a shared
helper (e.g., getReportedConversationListingIdsHelper) that accepts ctx and
reporter userId, reuse it from both getReportedConversationListingIds and
getReportedConversationListingIdSetForViewer, and ensure the helper normalizes
each report.targetId via normalizeId before looking up ctx.db.get so
unnormalized/foreign IDs aren't silently propagated; update both functions to
call the new helper and remove the duplicated mapping/lookup logic.
- Around line 920-1018: Add a one-line inline comment in the reportMessage flow
(near the call to hideConversationForParticipant inside the reportMessage
handler) explaining that we intentionally do not pass siblingConversationIds
here and therefore only hide the primary conversation, unlike
reportConversation/hideConversationFromInbox which hides siblings via
siblingConversationIds; reference the functions reportMessage,
reportConversation, hideConversationForParticipant, and
hideConversationFromInbox and the arg siblingConversationIds so future readers
understand the asymmetry is intentional.
In `@frontend/app/conversations/`[id].tsx:
- Around line 41-113: The component is misnamed—rename the function and any
exports from SwipeableMessageRow to a clearer name like ReportableMessageRow (or
MessageRowWithActions), keep the props and behavior unchanged, and update all
import sites to use the new identifier (including story/tests/parent components
that render it); also update any TypeScript types or exported names that
reference SwipeableMessageRow so the build and type checks remain consistent.
In `@frontend/components/ReportModal.tsx`:
- Around line 57-97: The handleSubmit function has duplicated payload objects
for reportConversation, reportMessage, and createReport calls with the same
shape { reason, notes: trimmedNotes }. Refactor this by creating a single
payload object containing reason and trimmedNotes before the if statement, then
await the appropriate reporting function with this shared payload. This reduces
duplication and keeps the branching logic focused only on calling the correct
function based on targetType.
🪄 Autofix (Beta)
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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f2f5015b-162c-4259-bc7c-7e00f0d2fd1d
📒 Files selected for processing (8)
backend/convex/__tests__/listings.test.tsbackend/convex/__tests__/messages.test.tsbackend/convex/listings.tsbackend/convex/messages.tsbackend/convex/schema.tsfrontend/app/(tabs)/inbox.tsxfrontend/app/conversations/[id].tsxfrontend/components/ReportModal.tsx
This was referenced Apr 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linked Issues
Closes #POLY-78
Linear: POLY-78
Summary
This PR adds moderation and inbox-management actions for messaging, aligned with the listing report flow.
In conversation view:
How to Test
Steps to verify locally:
npm run lintnpm run typechecknpm testnpm run dev:backend(in terminal A)npm run dev(in terminal B)Checklist
npm run lint)devScreenshots / Demos
Summary by CodeRabbit
Release Notes