fix: unified profile

[cameronvoell]

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

Note

Replace per-conversation DBMemberProfile with canonical DBProfile for unified identity storage

• Introduces canonical DBProfile, DBProfileAvatar, and related tables to store per-inbox identity and per-conversation avatar slots, replacing scattered DBMemberProfile lookups across messaging, streaming, and contact sync.
• Adds ProfilesRepository, ProfilePublisher, ProfileInboundApplier, and ProfileMerge to manage reactive profile reads, durable publish jobs, and precedence-based identity merges.
• Profile updates/snapshots in MessagingService and StreamProcessor now delegate to ProfileInboundApplier.apply instead of inline DBMemberProfile writes.
• InboxProfileAvatarView is introduced so contact rows and conversation avatars observe the unified profile stream by inboxId and update live.
• Asset renewal, expired asset recovery, agent verification, and contact sync are all rerouted from DBMemberProfile to DBProfileAvatar/DBProfile.
• ProfileBackfill migrates existing DBMemberProfile rows into the new canonical tables on service start.
• Risk: wide schema migration (new tables, dropped selfProfile table, new conversationLocalState column); existing databases are upgraded in place via SharedDatabaseMigrator.

^{Macroscope summarized 14ea335.}

[claude]

Claude finished @cameronvoell's task —— View job

---

PR Review: Unified Profile Architecture

This is a well-architected refactor that introduces a canonical profile system. The implementation is solid with strong test coverage and thoughtful design patterns.

✅ Strengths

Architecture & Design:

• Clean separation of concerns with ProfilesRepository as the canonical source
• Actor-based concurrency patterns prevent race conditions
• Proper precedence rules (contact < appData < profileSnapshot < profileUpdate)
• Dual caching strategy (in-memory cache + reactive GRDB ValueObservation)
• Non-clobbering migration via ProfileBackfill at lowest precedence
• Pure merge logic in ProfileMerge (no I/O, easily testable)

Code Quality:

• Comprehensive test coverage (24 test files covering core flows)
• Integration tests verify end-to-end profile persistence
• Clear documentation in implementation design doc
• Error handling with fallbacks (transient errors don't terminate streams)
• Idempotent operations (backfill, apply)

Security:

• Avatar encryption enforcement (rejects unencrypted avatars)
• Proper scoping (self profile queries filtered by current inbox)
• No plaintext avatar storage

⚠️ Issues to Address

High Priority

1. Profile table cleanup on account deletion (ProfilesRepository.swift:380)
The purgeConversationAvatars method only deletes avatars for a specific conversation, but there's no cleanup when an account is deleted. Legacy profile data (DBProfile, DBProfileAvatar, DBMyProfile, DBProfilePublishJob) will accumulate.

Recommendation: Add a purgeAccount(inboxId:) method called during account deletion that clears all profile tables for that inbox.

2. Task cancellation during teardown (ProfilePublisher.swift:69, ProfilesRepository.swift:288)
The ProfilePublisher.drain() task and other long-running operations aren't explicitly cancelled when the session tears down. This could leak background work.

Recommendation: Track the drain task and cancel it in unbind():

private var drainTask: Task<Void, Never>?

func attach(session: any ProfilePublishSession) async {
    // ...
    drainTask = Task { await drain() }
}

func detach() async {
    drainTask?.cancel()
    drainTask = nil
    // ...
}

3. Self-profile handling in associations (Automated review comment)
The repository applies a "skip self events" guard in apply(), but it's unclear if all entry points respect this. Need to verify that ProfileInboundApplier and other callers never attempt to store the current user's identity in DBProfile.

Recommendation: Add a runtime assertion or logging to catch violations during development.

Medium Priority

4. Cache invalidation race condition (ProfilesRepository.swift:151-166)
warmUp() loads the cache, but concurrent apply() calls during warmup could result in partial cache state. The warmedUp flag prevents re-warmup but doesn't block concurrent writes.

Recommendation: Consider using a continuation or task group to ensure warmup completes before processing events, or document that callers must await warmUp() before calling apply().

5. Error recovery in reactive publishers (ProfilesRepository.swift:68-86)
The profilePublisher() catches errors and returns empty profiles, but transient database errors (e.g., disk full, corruption) will silently surface as missing names/avatars to the UI with no user-facing feedback or retry.

Recommendation: Log errors to Sentry before returning .empty() so transient failures are visible.

6. Merge precedence documentation (ProfileMerge.swift:1-11)
The precedence hierarchy is documented in the file header but not in the ProfileSource enum definition itself, making it easy to misuse.

Recommendation: Add doc comments to ProfileSource with explicit ordering.

Low Priority

7. Test coverage gaps

• No tests for purgeConversationAvatars interaction with cache
• No tests for concurrent apply() calls during warmUp()
• No tests for ProfilePublisher.drain() retry/backoff behavior
• Missing test for leftover DBMyProfile from previous account (covered in code but not tested end-to-end)

Recommendation: Add tests for these edge cases.

8. Performance consideration
avatarsByInbox is a nested dictionary ([String: [String: DBProfileAvatar]]) that could grow large in accounts with many conversations. Consider measuring memory usage or adding eviction for inactive conversations.

Security

✅ No security concerns identified:

• All avatars are properly encrypted before storage
• Self-profile queries are scoped to current inbox
• No secrets in code or logs

Performance

✅ Generally efficient:

• In-memory cache reduces database reads
• ValueObservation provides reactive updates without polling
• ProfileMerge is pure (no I/O overhead)

⚠️ Potential concern:

• warmUp() loads all profiles into memory. For accounts with hundreds of contacts, this could be significant. Consider lazy loading or pagination if memory usage becomes an issue.

Test Coverage

✅ Strong coverage:

• 24 test files with unit, integration, and persistence tests
• ProfileMerge has comprehensive edge case coverage
• ProfileBackfill idempotency and non-clobbering verified
• End-to-end message-sourced profile persistence tested

Recommendations Summary

Before merge:

1. Add account deletion cleanup (purgeAccount)
2. Add task cancellation in unbind()
3. Verify/document self-profile handling in all entry points

Follow-up PRs:
4. Add error logging in reactive publishers
5. Document ProfileSource precedence ordering
6. Add test coverage for identified gaps
7. Monitor memory usage of avatarsByInbox in production

Overall, this is a high-quality refactor with solid foundations. The issues identified are addressable and don't block the core architecture.

[cameronvoell]

• fix: unified profile - global self profile #1131
• fix: unified profile - wire repository reads, self-publish, and self-profile freshness #1130
• fix: unified profile - activate backfill and populate live data #1129
• fix: unified profile - merge, repository, and unified profile #1128
• fix: unified profile #1126 👈 (View in Graphite)
• fix: prevent image cache from clobbering imageUrl for a given identifier #1116
• dev

---

How to use the Graphite Merge Queue

Add the label merge-queue to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.