Messaging#79
Conversation
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: alphaonelabs/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
WalkthroughAdds privacy-first direct messaging with request storage, authenticated request and thread APIs, activity participant contact actions, a Messages page chat interface, encrypted legacy-record persistence, notifications, and endpoint tests. ChangesPrivacy-first messaging
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant MessagesPage
participant MessagingAPI
participant MessageRequests
participant MessageThreads
User->>MessagesPage: Submit message request
MessagesPage->>MessagingAPI: POST request
MessagingAPI->>MessageRequests: Create pending request
User->>MessagesPage: Accept request
MessagesPage->>MessagingAPI: PATCH request
MessagingAPI->>MessageRequests: Update status
User->>MessagesPage: Send chat message
MessagesPage->>MessagingAPI: POST thread message
MessagingAPI->>MessageThreads: Store encrypted message
MessagesPage->>MessagingAPI: GET thread history
MessagingAPI->>MessageThreads: Decrypt and return messages
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ 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 review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 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 `@public/js/messaging.js`:
- Around line 317-331: Improve the polling interval in the DOMContentLoaded
handler so it skips loadActiveThreads, loadPendingRequests, and
refreshChatHistory when document.hidden is true, preventing unnecessary
background requests and DOM replacement while the tab is hidden.
In `@public/messages.html`:
- Line 48: Both inputs in public/messages.html need accessible names: update the
recipient email input at lines 48-48 and the chat message input at lines 96-101
with an aria-label or visually hidden label, using descriptive text such as
“Recipient email address” and “Type a message.”
- Around line 85-103: Update the chat modal container in public/messages.html
lines 85-103 with role="dialog", aria-modal="true", and
aria-labelledby="chat-title". In the chat modal open/close behavior around
public/js/messaging.js lines 220-261, add Escape-key dismissal, move focus into
the modal when opened, and restore focus to the previously focused element when
closed; optionally support closing by clicking the backdrop.
In `@schema.sql`:
- Around line 151-161: Strengthen the message_requests schema by enforcing one
request per user pair at the database level with a partial unique index that
normalizes from_user_id and to_user_id and excludes any intended non-active or
deleted states. Add an activity_id foreign key referencing the activities table
with the appropriate delete behavior, while preserving the existing user foreign
keys and defaults.
In `@src/worker.py`:
- Around line 6771-6789: Replace the per-row user lookups in
api_list_message_requests (src/worker.py lines 6771-6789), api_activity_contacts
(src/worker.py lines 6836-6859), and api_list_message_threads (src/worker.py
lines 6992-7016) with batched users queries using the collected IDs, then build
ID-to-display-name maps before assembling responses; for
api_list_message_threads, also consider aggregating the per-thread unread check.
- Around line 6817-6859: Restrict the contact-discovery flow after the access
check so users admitted solely through their interest cannot enumerate activity
participants or receive decrypted names. Update the gate and surrounding logic
to require verified enrollment or host status for participant lookup, or
otherwise withhold names until the relevant message request is mutually
accepted; preserve existing behavior for hosts and enrollees.
- Around line 6900-6903: Update the auto-created message request in the activity
flow to preserve recipient consent: insert it with a pending status instead of
accepted, while keeping the existing request identifiers, participants, source,
activity, and timestamp unchanged. Ensure the recipient must explicitly accept
before the thread becomes open and writable.
- Around line 6746-6755: Update api_respond_to_message_request so its
message_requests UPDATE only matches rows whose current status is 'pending'. Use
the update result to detect when no pending row was changed and return the
appropriate existing not-found or no-op response, preventing accepted or
declined requests from transitioning again.
- Around line 7057-7090: Update the legacy message-history fallback around the
query and row-processing logic to persist or otherwise expose each record’s
thread identifier as a queryable legacy_records column, then filter by the
requested thread_id in SQL before decrypting rows. Remove the
sender/receiver-only fallback that can mix messages from other threads, combine
the equivalent is_match conditions, and replace the per-row blind exception
suppression with explicit handling that preserves the existing outer
missing-table behavior while surfacing decryption or parsing failures.
🪄 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: Repository: alphaonelabs/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 0b08d79c-3323-4489-97d9-3741295b37b3
⛔ Files ignored due to path filters (1)
migrations/0012_add_message_requests.sqlis excluded by!**/migrations/**
📒 Files selected for processing (6)
public/activity-detail.htmlpublic/js/messaging.jspublic/messages.htmlschema.sqlsrc/worker.pytests/test_messaging.py
Screen.Recording.2026-07-23.195701.mp4
Summary
Extends the platform's messaging capabilities with a privacy-focused direct messaging system. Users can initiate direct message requests via exact email lookup or through shared activity enrollment. Reuses existing encrypted record storage (
legacy_records) with model aliasing (web.Message/web.PeerMessage).Key Changes
message_requeststable ([schema.sql], [migrations/0012_add_message_requests.sql], [src/worker.py]) with indexes on target user, sender, and activity.src/worker.py]):POST /api/messages/request: Email-initiated request with HMAC blind index lookup, 5 req/hr rate limiting, and neutral privacy response.PATCH /api/messages/request/:id: Accept or decline incoming message requests.GET /api/messages/requests: List pending requests for authenticated recipient showing sender name.GET /api/messages/threads: List active accepted conversation threads with unread indicators.GET /api/messages/threads/:id: Fetch decrypted message history and mark thread notifications as read.POST /api/messages/threads/:id/send: Send AES-256-GCM encrypted direct messages.GET /api/activities/:id/contacts&POST /api/activities/:id/message/:user_id: Enable activity participants and creators to connect directly.public/messages.html], [public/js/messaging.js], [public/activity-detail.html]):"You").tests/test_messaging.py]):Summary
Adds a privacy-focused direct messaging system with request-based communication, encrypted conversations, and activity participant messaging.
Key changes
message_requestsschema, indexes, and privacy-preserving email lookup with rate limiting.User impact
Users can initiate and manage direct conversations by email or through activities, with privacy-neutral responses and encrypted message storage.