fix(desktop): scope messaging sessions by profile

[protas-box]

Summary

Fixes profile routing for messaging-source sessions in the Desktop sidebar.

In multi-profile/global-remote setups, messaging sessions were fetched with profile=all regardless of the active profile. That made Telegram/other messaging sessions from one profile appear under another profile's sidebar section.

Clicking one of those messaging rows could also fail to open the transcript because resumeSession() only resolved the owning profile from the regular recents list ($sessions). Messaging rows live in $messagingSessions, so their profile was dropped before ensureGatewayProfile(), getSessionMessages(), and session.resume.

Changes

• Scope the messaging sidebar fetch and per-platform "load more" fetch to the active profile, matching the regular recents list behavior.
• Keep all behavior when the sidebar is explicitly in all-profiles mode.
• Include profile, source, and last_active in the messaging/cron section signature so profile/source changes update the atom instead of keeping stale rows.
• Resolve the session owner from $messagingSessions and $cronSessions as fallbacks before resuming a stored session.

Validation

• npm run typecheck --workspace apps/desktop
• Manual validation with a remote Hermes backend serving multiple profiles:
  • Telegram sessions created under profile pm no longer appear in the default profile messaging section.
  • The same Telegram sessions open correctly from the pm profile and hydrate the stored transcript.

[tonydwb]

Code Review: PR #44157

Verdict: Approved — correct profile scoping fix for messaging sessions.

Summary

• Files changed: apps/desktop/src/app/desktop-controller.tsx (+30, -10), apps/desktop/src/app/session/hooks/use-session-actions.ts (+6, -1)
• Scopes messaging sidebar fetch and load-more to the active profile instead of always using 'all'
• Includes profile, source, and last_active in section signature for proper stale-detection
• Resolves session owner from messagingSessions and cronSessions as fallbacks

Assessment

Correctness: The fallback chain sessions -> messagingSessions -> cronSessions ensures session owner is found regardless of which list the session lives in.

No issues found.

---

Reviewed by Hermes Agent

[teknium1]

Thanks for tracing both the sidebar fetch and resume-owner paths. The underlying bug still exists on current main, but this branch needs a targeted port before it is safe to salvage.

Problems

• The production fetches were extracted by 25c7900fb into apps/desktop/src/app/session/hooks/use-session-list-actions.ts; current refreshMessagingSessions and loadMoreMessagingForPlatform still hardcode profile="all" at lines 102 and 126, while refreshCronSessions has the same sibling defect at line 86.
• The current regular-recents path guards stale async responses with refreshSessionsRequestRef at use-session-list-actions.ts:155-188. The proposed messaging scope change has no equivalent guard, so a result begun before a profile switch can publish old-profile rows afterward.
• Current resolveStoredSession is now apps/desktop/src/app/session/hooks/use-session-actions/utils.ts:208; it still searches only $sessions, so the proposed messaging/cron fallback should be ported there.

Suggested changes

• Rework the patch at those current locations, scope cron too, and add per-operation request-generation guards.
• Add tests for active-profile and all-profiles fetches, messaging/cron owner resolution, and stale-result suppression.

Automated hermes-sweeper review.

[teknium1]

Please guard this async profile-scoped fetch with a request generation counter before publishing rows. If the user switches profiles while this request is in flight, its late result can overwrite the new profile's messaging section; current main's regular-recents refresh already uses this pattern.

[yewangmu]

Current-main port validation for messaging/cron cache resolution

I hit the second symptom described by this PR on current Desktop: clicking a row already present in $messagingSessions caused resolveStoredSession() to miss the cache, fetch by ID, and insert the same row into $sessions, so one conversation rendered in both sidebar sections.

The current location is now:

apps/desktop/src/app/session/hooks/use-session-actions/utils.ts

A minimal current-main port is to resolve from regular, cron, and messaging caches before performing by-ID lookup:

const cached = [...$sessions.get(), ...$cronSessions.get(), ...$messagingSessions.get()].find(session =>
  sessionMatchesStoredId(session, storedSessionId)
)

I added a focused regression in:

apps/desktop/src/app/session/hooks/use-session-actions/resolve-stored-session.test.ts

The test seeds a Telegram row only in $messagingSessions, calls resolveStoredSession(), and verifies:

• the exact cached row is returned;
• getSession() is not called;
• $sessions stays empty.

TDD evidence: the new test failed on current main because the resolver returned undefined, then passed after the cache fallback was ported.

Validation on current origin/main (Windows 11):

• targeted tests passed;
• npm run typecheck passed;
• npm run lint passed with 0 errors (existing warnings only);
• full UI suite passed: 414 files, 3695 tests;
• git diff --check passed;
• local Electron candidate was exercised with live LINE/Telegram/Discord/WeChat sessions; selecting messaging rows no longer duplicated them into generic Sessions.

I have not opened a competing PR because this PR already contains the same underlying fallback on the pre-refactor file. I can provide the two-file current-main port as an incremental patch if useful.

[teknium1]

Resolved on main by #87566, which consolidated this PR's fix with your Co-authored-by credit preserved in the merged commits. Thank you!