fix(lifeops): keep proactive digests to personal inboxes#7889
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
LifeOps Benchmark —
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| export function proactiveInboxDigestRequest(): GetLifeOpsInboxRequest { | ||
| return { | ||
| ...PROACTIVE_INBOX_DIGEST_REQUEST, | ||
| channels: [...(PROACTIVE_INBOX_DIGEST_REQUEST.channels ?? [])], |
There was a problem hiding this comment.
?? [] fallback on a non-optional field
PROACTIVE_INBOX_DIGEST_REQUEST.channels is always defined — it is a typed literal in the same file — so the ?? [] branch is unreachable dead code. If the intention is purely defensive copying (in case a caller mutates the returned array), the plain spread [...PROACTIVE_INBOX_DIGEST_REQUEST.channels] communicates that intent more clearly without implying the value could be absent.
| ]); | ||
| expect(request.channels).not.toContain("discord"); | ||
| expect(request.channels).not.toContain("telegram"); | ||
| expect(request.channels).not.toContain("signal"); |
There was a problem hiding this comment.
toEqual
The three not.toContain assertions (discord, telegram, signal) are logically implied by the preceding expect(request.channels).toEqual([...]) which already pins the exact contents of the array. If toEqual passes, the array cannot contain any element outside the expected list. Removing the three assertions avoids coupling the test to an implementation-level concern that is already fully covered.
| // the inbox layer conservatively marks them unread so explicit inbox views | ||
| // can still triage them. Proactive digests should only summarize channels | ||
| // with personal inbox semantics until chat read/mention state is grounded. | ||
| channels: ["gmail", "x_dm", "imessage", "whatsapp", "sms"], |
There was a problem hiding this comment.
signal excluded from proactive personal inbox channels
The LIFEOPS_INBOX_CHANNELS set contains "signal", and Signal is a personal end-to-end encrypted messenger whose read state is owned by the user (similar to iMessage/WhatsApp). The PR description groups it with chat connectors (Discord, Telegram) as a reason for exclusion, but Signal is not a server/community platform. Was this omission intentional, or should "signal" be included alongside the other personal messaging channels? Was signal intentionally excluded from the proactive digest channels, or should it be included alongside iMessage/WhatsApp?
LifeOps Benchmark —
|
|
CI note after the first run: Validated locally on the branch:
The current red jobs do not appear to be caused by this LifeOps digest change:
Keeping this PR scoped to the proactive digest fix rather than chasing those unrelated lanes here. |
2 participants
Summary
Prevents proactive LifeOps GM/GN inbox digests from summarizing chat connector memories as unread personal inbox items.
Why
During live local-source testing, the proactive worker sent a night summary DM that included stale Discord test-channel messages as "unread" inbox highlights. The root cause is that chat connector memories do not yet carry reliable per-owner read state; the inbox layer conservatively marks those cached chat items unread so explicit inbox views can still triage them. Proactive digests should not use that same broad channel set for unsolicited owner DMs.
Change
proactiveInboxDigestRequest()policy helper for the proactive worker.Validation
bunx @biomejs/biome check --write src/activity-profile/proactive-worker.ts src/activity-profile/proactive-inbox-digest.ts test/proactive-worker.test.ts --no-errors-on-unmatchedbun test --timeout 30000 test/proactive-worker.test.tsbun run buildELIZA_DISABLE_PROACTIVE_AGENT=1and restarting, logs show[proactive] Proactive agent task skipped — ELIZA_DISABLE_PROACTIVE_AGENT=1and no new GN digest fired after restart.Greptile Summary
Scopes proactive GM/GN inbox digests to personal messaging channels only (Gmail, X DMs, iMessage, WhatsApp, SMS) to prevent stale chat-connector memories (Discord, Telegram, Signal) from surfacing as "unread" highlights in unsolicited owner DMs.
proactiveInboxDigestRequest()helper inproactive-inbox-digest.ts, replacing the bare{ limit: 24 }call inloadInboxDigest.missedOnly: true,groupByThread: true, andsortByPriority: truealongside the explicit channel allow-list; theresolveInboxRequestpath inservice-mixin-inbox.tscorrectly falls back to all channels whenchannelsis omitted, so explicit inbox views are unaffected.Confidence Score: 4/5
Safe to merge; the change is narrowly scoped to the proactive digest path and does not touch explicit inbox views or shared data structures.
The fix is correct and well-contained. The only open question is whether
signalbelongs in the personal-channel allow-list alongside iMessage and WhatsApp — its omission could silently suppress Signal DMs from proactive digests if the connector is in use.The new
proactive-inbox-digest.tsfile deserves a quick check on thesignalchannel exclusion decision.Important Files Changed
?? []fallback on a non-optional field and the intentional omission ofsignalare worth a second look.loadInboxDigestnow usesproactiveInboxDigestRequest()instead of the bare{ limit: 24 }object, correctly delegating channel scoping to the new policy helper.not.toContainassertions are redundant given the priortoEqualcheck.Sequence Diagram
sequenceDiagram participant PW as proactive-worker participant PID as proactiveInboxDigestRequest() participant SVC as LifeOpsService.getInbox() participant RIR as resolveInboxRequest() PW->>PID: call proactiveInboxDigestRequest() PID-->>PW: "{ limit:24, channels:[gmail,x_dm,imessage,whatsapp,sms], missedOnly:true }" PW->>SVC: getInbox(request) SVC->>RIR: resolveInboxRequest(request) RIR-->>SVC: "allowed = Set{gmail, x_dm, imessage, whatsapp, sms}" Note over RIR: chat channels (discord, telegram, signal) NOT in allowed set SVC-->>PW: LifeOpsInbox (personal channels only) PW->>PW: build InboxDigestSlim for GM/GN DMReviews (1): Last reviewed commit: "fix(lifeops): keep proactive digests to ..." | Re-trigger Greptile