Details modal refactor - fix type issues; Fix showing events synced back from gcal; Add loading limit for sidebar event fetch#56
Details modal refactor - fix type issues; Fix showing events synced back from gcal; Add loading limit for sidebar event fetch#56
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Comment |
|
problems remaining:
|
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| try { | ||
| const res = await api.get(`/events/occurrences`, { | ||
| headers: { "Clerk-User-Id": userID }, | ||
| params: { term, tags, date, limit: LIMIT, offset }, |
There was a problem hiding this comment.
Bug: The fetchMore function sends the raw tags object array in its API call instead of the computed selectedTagIds string, breaking pagination when tag filters are active.
Severity: HIGH
Suggested Fix
In the params object for the axios.get call within the fetchMore function, replace tags with tags: selectedTagIds to ensure the API receives a comma-separated string of tag IDs, consistent with the initial fetch.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/app/explore/useExploreEvents.ts#L68
Potential issue: In the `fetchMore` function, the API call for paginated results
incorrectly uses the `tags` parameter, which is an array of objects (`OptionType[]`),
instead of the correctly computed `selectedTagIds` string. The initial fetch correctly
uses the string format. This discrepancy means that when a user applies tag filters and
scrolls to load more results, the backend receives malformed query parameters. This will
likely cause the pagination to fail or ignore the active tag filters, leading to
incorrect results being displayed.
Did we get this right? 👍 / 👎 to inform future reviews.
| ends, | ||
| eventId: dbRecurrence.event_id, | ||
| selectedDays, | ||
| nthWeek: dbRecurrence.by_month_day ?? null, // optional mapping, depends on your monthly logic |
There was a problem hiding this comment.
Bug: The dbRecurrenceToForm function incorrectly maps dbRecurrence.by_month_day to nthWeek, causing issues when editing monthly recurring events.
Severity: HIGH
Suggested Fix
Update dbRecurrenceToForm to correctly handle recurrence data. It should parse nthWeek from the by_day array (e.g., extracting -1 from "-1FR"). The by_month_day value should be mapped to a separate form field that represents the day of the month, not nthWeek.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/app/utils/dateService.ts#L204
Potential issue: The `dbRecurrenceToForm` function incorrectly maps the `by_month_day`
database field to the `nthWeek` form field. The `by_month_day` field stores the day of
the month (e.g., 15), while `nthWeek` is for specifying recurrence on a certain week
(e.g., the 3rd Friday). This causes incorrect data to be loaded into the event editor
for monthly events recurring on a specific date. When the user saves, this can lead to a
malformed recurrence rule being generated and stored, as `nthWeek` will have an invalid
value.
Did we get this right? 👍 / 👎 to inform future reviews.
2 participants
Name of PR:
1. Issue
Link to the associated GitHub/Notion issue:
(or describe the issue if you don't have a link)
#39
2. Changes
What changes did you make to resolve the issue?
(bullet point format is fine)
Does your change introduce new dependencies to this project? If so, list here.
3. Validation
How did you trigger the change to show that it is working?
(bullet point format is fine)
Attach screenshot(s) of the logs and UI demonstrating the change.