Skip user activity tracking in local dev#1181
Conversation
User activity is collaborator presence ("who else is editing this site") — it
filters out your own activity and only surfaces other users. In local dev
(single user, no collaborators) it has nothing to show, and listing it tries to
resolve activity rows that point at since-deleted pages, throwing a flood of
404s and ZodErrors in the editor console.
Gate both ends on instance.dev_mode: setUserActivity no longer writes presence
records locally, and getUserActivity returns [] instead of listing/resolving
them. Mirrors the existing dev_mode gating used elsewhere (e.g. Deploy).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesDev-mode user activity gating
🎯 1 (Trivial) | ⏱️ ~2 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
Problem
Opening the editor in local dev (
primo dev) floods the console with repeating errors:user_activitiesis a collaborator-presence feature — it tracks "who else is editing this site" andgetUserActivityexplicitly filters out your own activity to show only other users. In local dev there are no other users, so it has nothing to show. Worse, listing it resolves activity rows whosepagepoints at since-deleted pages → a 404 per stale row → the related-record resolver gets a nullid→ ZodError, looping over the list.This was previously masked by an unrelated render crash (fixed in #1179 / v3.2.1); with that gone, the editor proceeds far enough to surface this noise.
Fix
Gate both ends on the existing
instance.dev_modeflag (same signal already used byDeploy.svelte):setUserActivityreturns early in dev — don't write presence churn to the local DB.getUserActivityreturns[]in dev — don't list/resolve activities (the part that throws).This is a design fix, not a defensive patch: the feature simply shouldn't run in single-user local dev.
Verification
Built a local server binary embedding this change and ran it via
PRIMO_BINARYagainst a real local workspace:user_activitiesZodErrors.user_activitiesflood is gone; editor renders and works normally.(One unrelated benign 404 for a single deleted-page reference remains — a separate dangling-reference issue, out of scope here.)
Production build (
vite build) passes. The only svelte-check findings in the file are pre-existingTimeout-vs-numbertype nits unrelated to this change.🤖 Generated with Claude Code
Summary by CodeRabbit