fix(meetings): stop treating maybe RSVPs as pending actions

[manishdixitlfx]

Summary

A "maybe" RSVP is a valid response — the user has answered — so it should not appear as pending. Before this fix, two places incorrectly nagged users who had already maybe-RSVPed:

• Dashboard Pending Actions panel kept emitting a "Set RSVP" action for meetings the user had already answered with "maybe".
• /meetings Pending RSVP filter chip (shipped in feat(meetings): add pending rsvp filter on me-lens meetings #553 / LFXV2-1545) surfaced maybe-responded meetings as still pending.

After this fix, pending = no RSVP recorded at all. accepted, declined, and maybe are all valid responses.

Changes

• apps/lfx-one/src/server/services/user.service.ts — transformMissingRsvpsToActions: simplified to a Set<meeting_id> of any recorded response. Dropped the "strongest-response-wins" reducer since we only need existence now. Updated getUserPendingActions docstring and the transformer's own docstring.
• apps/lfx-one/src/app/modules/meetings/meetings-dashboard/meetings-dashboard.component.ts — filter predicate simplified to !m.my_rsvp. Comment updated.

Notes

• The strongest-response tiebreaker in getUserMeetings (line ~559) stays — it decides which MeetingRsvp to attach to meeting.my_rsvp when there are multiple, which is still a valid semantic for any future UI that displays the response type.
• No frontend type changes. No upstream contract changes.

LFXV2-1569

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[coderabbitai]

Walkthrough

The changes narrow the definition of pending RSVP status from including "maybe" responses to only meetings with no recorded RSVP, applying this stricter filter consistently on both client and server sides.

Changes

Cohort / File(s)	Summary
RSVP Filtering Logic apps/lfx-one/src/app/modules/meetings/meetings-dashboard/meetings-dashboard.component.ts, apps/lfx-one/src/server/services/user.service.ts	Narrowed pending RSVP determination from "missing or maybe" to "missing only." Removed the condition that included "maybe" RSVP responses in pending-only filters, and simplified the server-side detection from a prioritized map to a simpler set-based approach.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: moving from treating 'maybe' RSVPs as pending to no longer treating them as pending, which is the core intent of this fix across both modified files.
Description check	✅ Passed	The description clearly explains the problem, the solution, and the specific files changed, directly relating to the changeset and providing context for the modifications made.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/LFXV2-1569-maybe-not-pending

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

Adjusts meeting RSVP “pending” semantics so a maybe response is treated as a completed RSVP (i.e., only missing RSVPs are considered pending). This aligns the dashboard’s Pending Actions and the /meetings Pending RSVP filter with the corrected definition.

Changes:

• Server: transformMissingRsvpsToActions now treats any recorded RSVP (including maybe) as responded, emitting “Set RSVP” only when no RSVP exists.
• Client: Pending RSVP filter now shows meetings only when my_rsvp is absent/null.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
apps/lfx-one/src/server/services/user.service.ts	Updates pending-action RSVP logic to “missing only” and refreshes relevant docstrings.
apps/lfx-one/src/app/modules/meetings/meetings-dashboard/meetings-dashboard.component.ts	Updates Pending RSVP filter predicate to !m.my_rsvp and refreshes comment to match new semantics.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

🧹 Nitpick comments (1)

apps/lfx-one/src/server/services/user.service.ts (1)

1144-1147: Update related comment in getUserMeetings to avoid logic drift.

The new docstring is correct, but Line 550 still says it uses the “same logic as transformMissingRsvpsToActions,” which is no longer true after this change.

Suggested comment-only patch

-        // Strongest-response-wins (accepted/declined beats maybe beats nothing) — same logic as
-        // `transformMissingRsvpsToActions`. Drop RSVPs whose `registrant_id` isn't in the active
+        // Strongest-response-wins (accepted/declined beats maybe beats nothing) for `meeting.my_rsvp`
+        // display enrichment. This is intentionally separate from pending-action RSVP logic.
+        // Drop RSVPs whose `registrant_id` isn't in the active

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/lfx-one/src/server/services/user.service.ts` around lines 1144 - 1147,
The comment above getUserMeetings is outdated—update its docstring to remove the
statement that it "uses the same logic as transformMissingRsvpsToActions" and
replace it with a concise description of the current behavior: that
getUserMeetings emits a "Set RSVP" action for in-window meetings where a user
has no recorded RSVP (treating accepted/declined/maybe and any per-occurrence
RSVP as non-missing), and note any differences from
transformMissingRsvpsToActions if applicable; locate the getUserMeetings doc
comment and edit the text to reflect this exact behavior and to call out that
per-occurrence RSVPs count toward the series so users aren't re-nagged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@apps/lfx-one/src/server/services/user.service.ts`:
- Around line 1144-1147: The comment above getUserMeetings is outdated—update
its docstring to remove the statement that it "uses the same logic as
transformMissingRsvpsToActions" and replace it with a concise description of the
current behavior: that getUserMeetings emits a "Set RSVP" action for in-window
meetings where a user has no recorded RSVP (treating accepted/declined/maybe and
any per-occurrence RSVP as non-missing), and note any differences from
transformMissingRsvpsToActions if applicable; locate the getUserMeetings doc
comment and edit the text to reflect this exact behavior and to call out that
per-occurrence RSVPs count toward the series so users aren't re-nagged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a22a3550-7bb8-4e2c-b21c-dac4e769a920

📥 Commits

Reviewing files that changed from the base of the PR and between 1daaa69 and 78944b0.

📒 Files selected for processing (2)

• apps/lfx-one/src/app/modules/meetings/meetings-dashboard/meetings-dashboard.component.ts
• apps/lfx-one/src/server/services/user.service.ts