Refactor sync interval and update customer segment in various components - #7
Conversation
Reviewer's GuideRefactors the customer reservation workflow to start the reservation instance when opening the booking modal and confirm it directly on slot selection, removes the intermediate confirm-reservation modal and polling logic, adds loading feedback when opening a booking, speeds up chat sync intervals, and updates a mock customer segment value. Sequence diagram for updated customer reservation workflowsequenceDiagram
participant Dashboard
participant RezervationRuntime
rect rgb(230,230,250)
Dashboard->>RezervationRuntime: startInstance
RezervationRuntime-->>Dashboard: { id: instanceId }
Dashboard->>Dashboard: setBookModal(advisorKey, advisorType, instanceId)
end
rect rgb(230,250,230)
Dashboard->>RezervationRuntime: runTransition(confirm-selection, instanceId, attributes)
RezervationRuntime-->>Dashboard: confirmRes
Dashboard->>Dashboard: extractWorkflowCurrentState(confirmRes.data)
alt state !== active && state !== slot-unavailable && state !== ""
loop until state is active or slot-unavailable
Dashboard->>Dashboard: delay(320)
Dashboard->>RezervationRuntime: getInstance(instanceId)
RezervationRuntime-->>Dashboard: instanceData
Dashboard->>Dashboard: extractWorkflowCurrentState(instanceData)
end
end
alt state === slot-unavailable
Dashboard->>Dashboard: toast("Bu slot artık müsait değil")
else state === active || state === ""
Dashboard->>Dashboard: setReservationSuccessModalOpen(true)
Dashboard->>Dashboard: setBookModal(null)
else
Dashboard->>Dashboard: toast("Randevu tamamlanamadı")
end
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThis PR optimizes Matrix sync polling intervals from 2000ms to 200ms across chat components, and refactors the customer dashboard booking workflow from a two-step modal flow with polling confirmation to a single-step flow that creates the reservation instance on modal open and confirms via direct transition on user action. A test customer segment value is also updated. ChangesMatrix Sync Polling Optimization
Dashboard Booking Flow Consolidation
🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The
SYNC_MIN_INTERVAL_MSconstant is now duplicated acrossVideoCallMatrixChat,ChatManagement, andcustomer/Chat; consider centralizing this in a shared config/module so future tuning only needs to happen in one place. - The
handleBookSaveflow contains several hard-coded polling parameters (14 iterations, 320ms delay, specific state checks) that mirror patterns used elsewhere; extracting this workflow-polling/transition logic into a reusable helper would make the behavior easier to tweak and reason about.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `SYNC_MIN_INTERVAL_MS` constant is now duplicated across `VideoCallMatrixChat`, `ChatManagement`, and `customer/Chat`; consider centralizing this in a shared config/module so future tuning only needs to happen in one place.
- The `handleBookSave` flow contains several hard-coded polling parameters (14 iterations, 320ms delay, specific state checks) that mirror patterns used elsewhere; extracting this workflow-polling/transition logic into a reusable helper would make the behavior easier to tweak and reason about.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the reservation booking flow in the Dashboard, moving instance creation to the start of the process and removing the intermediate summary modal. It also reduces the synchronization interval for chat components from 2000ms to 200ms. Feedback focuses on the significantly reduced polling timeout in the new booking logic, which may lead to errors, and the potential for high server load due to the aggressive chat synchronization frequency.
| toast('Randevu oluşturuldu; onay için danışman ile iletişime geçin.', 'success'); | ||
| let stateStr = extractWorkflowCurrentState(confirmRes.data); | ||
| if (stateStr !== 'active' && stateStr !== 'slot-unavailable') { | ||
| for (let i = 0; i < 14 && stateStr !== 'active' && stateStr !== 'slot-unavailable'; i += 1) { |
There was a problem hiding this comment.
The polling timeout has been significantly reduced in this refactor. The previous implementation (removed useEffect) allowed for approximately 29 seconds of polling (45 attempts * 650ms). The new logic only allows for about 4.5 seconds (14 attempts * 320ms). If the backend process for confirming a reservation takes longer than 4.5 seconds, the user will receive a "Randevu tamamlanamadı" error even if the operation eventually succeeds. Consider increasing the number of attempts to match the previous timeout duration.
| for (let i = 0; i < 14 && stateStr !== 'active' && stateStr !== 'slot-unavailable'; i += 1) { | |
| for (let i = 0; i < 45 && stateStr !== 'active' && stateStr !== 'slot-unavailable'; i += 1) { |
| import { customerDisplayName, getCustomerName } from '../data/customers'; | ||
|
|
||
| const SYNC_MIN_INTERVAL_MS = 2000; | ||
| const SYNC_MIN_INTERVAL_MS = 200; |
There was a problem hiding this comment.
The reduction of SYNC_MIN_INTERVAL_MS from 2000ms to 200ms is a significant change. While it improves responsiveness, it also increases the frequency of requests by 10x. Given the comment on line 28 of ChatManagement.tsx (and similar files) about avoiding "hammering the runtime", 200ms might be too aggressive for a long-polling loop, potentially leading to high server load if many clients are active simultaneously. Please consider if a slightly higher value (e.g., 500ms or 1000ms) would be a safer middle ground.
2 participants
Summary by Sourcery
Simplify the customer reservation workflow while speeding up chat/video sync and correcting a mock customer segment.
Bug Fixes:
Enhancements:
Summary by CodeRabbit
Performance Improvements
Features
Data Updates