fix(console): correct earlier context_type fix, backend requires a st… - #102
Conversation
…ring Follow-up to my earlier fix in this PR that changed the blank fallback from the stale selectedMemory.context_type to null. That was wrong: an independent review caught that marm-mcp-server's internal endpoint declares context_type as a required non-empty str (min_length=1), and its recall path calls .upper() on it unconditionally -- sending null gets rejected with a 422, it doesn't clear the field. The Console-side correction (restoring the backend's blank-to-'general' coercion) landed separately on fix/console-memory-context-type-null since the branch that originally carried this contract (refactor/console-app-py-split) had already merged. This commit fixes the actual root cause the CodeRabbit finding was pointing at: the fallback used the memory's previous context_type (stale) instead of a fixed default. The correct fallback is 'general' -- the same default already used for new memories -- not null. tsc --noEmit clean, npm run build succeeds. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s8tBNnQTmb1q5nRAKwhvv
|
Warning Review limit reached
Next review available in: 14 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesMemory context type handling
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
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 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
marm-console/artifacts/marm-console/src/components/memory/MemoriesTab.tsx (1)
372-372: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUpdate placeholder to reflect new fallback behavior.
The placeholder explicitly states
(blank = null), which contradicts the new logic where a blank field is saved as'general'. This creates a user-facing correctness bug.🐛 Proposed fix
- <Input placeholder="Context type (blank = null)" value={editContextType} onChange={e => setEditContextType(e.target.value)} className="text-xs" /> + <Input placeholder="Context type (blank = 'general')" value={editContextType} onChange={e => setEditContextType(e.target.value)} className="text-xs" />🤖 Prompt for 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. In `@marm-console/artifacts/marm-console/src/components/memory/MemoriesTab.tsx` at line 372, Update the placeholder on the context-type Input in MemoriesTab so it states that a blank value is saved as “general,” matching the existing fallback behavior; leave the value and change-handler logic unchanged.
🤖 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.
Outside diff comments:
In `@marm-console/artifacts/marm-console/src/components/memory/MemoriesTab.tsx`:
- Line 372: Update the placeholder on the context-type Input in MemoriesTab so
it states that a blank value is saved as “general,” matching the existing
fallback behavior; leave the value and change-handler logic unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 1c68d569-602a-4231-a40e-f883ee214df8
📒 Files selected for processing (1)
marm-console/artifacts/marm-console/src/components/memory/MemoriesTab.tsx
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
- GitHub Check: Analyze (actions)
- GitHub Check: Analyze (python)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
marm-console/artifacts/marm-console/src/components/memory/MemoriesTab.tsx (1)
150-173: LGTM!
CodeRabbit follow-up. The placeholder still said 'blank = null' after the earlier fix changed a cleared context type to fall back to 'general' instead. Copy-only change, no logic touched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011s8tBNnQTmb1q5nRAKwhvv
…ring
Follow-up to my earlier fix in this PR that changed the blank fallback from the stale selectedMemory.context_type to null. That was wrong: an independent review caught that marm-mcp-server's internal endpoint declares context_type as a required non-empty str (min_length=1), and its recall path calls .upper() on it unconditionally -- sending null gets rejected with a 422, it doesn't clear the field. The Console-side correction (restoring the backend's blank-to-'general' coercion) landed separately on fix/console-memory-context-type-null since the branch that originally carried this contract (refactor/console-app-py-split) had already merged.
This commit fixes the actual root cause the CodeRabbit finding was pointing at: the fallback used the memory's previous context_type (stale) instead of a fixed default. The correct fallback is 'general' -- the same default already used for new memories -- not null.
tsc --noEmit clean, npm run build succeeds.
Claude-Session: https://claude.ai/code/session_011s8tBNnQTmb1q5nRAKwhvv
Summary by CodeRabbit