bugfix: activity log and journal description not updating without pag…#231
Conversation
|
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 48 minutes and 0 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: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe component refactors activity-log refresh logic by introducing a centralized Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
frontend/src/pages/CaseDetail.jsx (1)
68-78: Nice consolidation.Centralizing the activity-log refresh into
refetchActivityLog()removes the duplicatedgetLogsByRecord+setTimelineplumbing from each mutation handler, and theprev.filter(i => i.type !== 'ACTIVITY')approach correctly preserves locally-appendedCOMMENTentries added optimistically inhandleSendMessage.One optional hardening: if the user navigates away (
caseData.idchanges) while a refetch is in flight, the latesetTimelinecould write logs for the previous record into the new view. A simple guard is to capture the id and bail out on mismatch:Optional: ignore stale in-flight responses after
caseData.idchangesconst refetchActivityLog = async () => { + const requestedId = caseData.id; try { - const logsRes = await activityService.getLogsByRecord(caseData.id); + const logsRes = await activityService.getLogsByRecord(requestedId); + if (requestedId !== caseData.id) return; setTimeline(prev => [ ...prev.filter(i => i.type !== 'ACTIVITY'), ...logsRes.data.map(l => ({ ...l, type: 'ACTIVITY' })) ].sort((a, b) => new Date(b.createdAt) - new Date(a.createdAt))); } catch (error) { console.error("Kunde inte uppdatera aktivitetsloggen:", error); } };🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@frontend/src/pages/CaseDetail.jsx` around lines 68 - 78, refetchActivityLog can race with navigation: capture the current case id at the start (const currentId = caseData.id) and before calling setTimeline validate that caseData.id === currentId; if not, return early to avoid writing logs for a stale case. Update the refetchActivityLog function (and any callers like handleSendMessage that rely on it) to perform this guard using the captured id before merging logs via setTimeline so late responses don't overwrite the timeline for a newly-selected case.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@frontend/src/pages/CaseDetail.jsx`:
- Around line 25-31: The header is still reading caseData.title while the
journal uses editedTitle/editedDescription and handleSaveRecord doesn't update
local state or notify the parent; fix by making the component use the same local
state for both header and body and keeping that state in sync after saves:
change the header rendering (where it currently uses caseData.title) to use
editedTitle/editedDescription/localStatus, update the sync useEffect (currently
watching [caseData?.id]) to watch the relevant fields (e.g., [caseData?.id,
caseData?.title, caseData?.description, caseData?.status]) so incoming server
updates reset local state, and modify handleSaveRecord to apply the server
response to setEditedTitle/setEditedDescription/setLocalStatus and/or call an
optional onUpdated callback passed from the parent to trigger a refetch; ensure
setEdited* is called with the saved values so header/body remain consistent.
---
Nitpick comments:
In `@frontend/src/pages/CaseDetail.jsx`:
- Around line 68-78: refetchActivityLog can race with navigation: capture the
current case id at the start (const currentId = caseData.id) and before calling
setTimeline validate that caseData.id === currentId; if not, return early to
avoid writing logs for a stale case. Update the refetchActivityLog function (and
any callers like handleSendMessage that rely on it) to perform this guard using
the captured id before merging logs via setTimeline so late responses don't
overwrite the timeline for a newly-selected case.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d0f78813-33b1-4310-a5c3-46942004faa7
📒 Files selected for processing (1)
frontend/src/pages/CaseDetail.jsx
1 participant
…e reload (#219)
Summary by CodeRabbit