guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

syncLog vs syncHealth #314

New Issue
Open
opened 2026-05-28 03:00:51 +00:00 by guettli · 2 comments
guettli commented 2026-05-28 03:00:51 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

For an end user "syncLog vs syncHealth" is confusing, because they expect that there is one sync which does both.

Create a plan. What about joining both features?

What would be the drawback?

Or is it better to keep both features distinct?

For an end user "syncLog vs syncHealth" is confusing, because they expect that there is one sync which does both. Create a plan. What about joining both features? What would be the drawback? Or is it better to keep both features distinct?
guettlibot commented 2026-05-28 03:54:09 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Implementation Plan: Joining syncLog and syncHealth

Current State

syncLog and syncHealth serve fundamentally different roles:

Aspect syncLog syncHealth
Purpose Audit trail of every sync cycle Periodic verification that local cache matches server
Trigger After every sync cycle (continuous) Hourly timer + manual (periodic)
Storage Last 100 entries per account (history) Single row per account (current state only)
Data Emails fetched/skipped, bytes, errors, stack traces Boolean health flag + per-mailbox discrepancy counts
UI entry Dedicated "Sync log" screen Status indicator on account tile in AccountListScreen

Key files:

  • lib/data/db/database.dart lines 178–228 — SyncLogs, SyncLogMailboxes, SyncHealth tables
  • lib/core/sync/account_sync_manager.dart lines 238–251, 493–507 — writes syncLog after each IMAP/JMAP cycle
  • lib/core/sync/reliability_runner.dart — runs health verification hourly + on demand
  • lib/ui/screens/sync_log_screen.dart — full audit history UI
  • lib/ui/screens/account_list_screen.dart lines 120–157 — health status display
  • lib/di.dart lines 109–136 — syncLogRepositoryProvider, syncHealthProvider, reliabilityRunnerProvider

Options

Option A: Full Data Model Merge

Collapse the two database tables into one concept. Each sync cycle entry would also carry health information; the periodic health check would produce an entry tagged as a "verification" type.

Drawbacks:

  • The data shapes are genuinely different. syncLog keeps a rolling 100-entry history; syncHealth is a single mutable row. Merging them forces an awkward compromise: either pollute the log with nullable health columns or discard history for health checks.
  • The triggers are independent: syncLog fires after every sync cycle, syncHealth fires on a timer. Coupling them means a health check gap whenever syncing is paused, or spurious log entries whenever the health timer fires.
  • Schema migration required (Drift migration to drop/alter tables).
  • Increased complexity with no real UX benefit — the user confusion is about navigation, not underlying data.

Verdict: Not recommended.

Option B: Unified UI Entry Point (Recommended)

Keep both data models exactly as-is, but merge the user-facing surface into a single "Sync" screen. The unified screen shows:

  1. Health banner at the top — healthy/discrepancy status with last-verified timestamp and a manual "Verify now" button (currently scattered across the account tile menu).
  2. Sync history below — the existing log list, exactly as today.

This eliminates the user confusion ("two different sync things") without touching the data layer.

Files to change:

File Change
lib/ui/screens/sync_log_screen.dart Rename to sync_screen.dart / SyncScreen. Add a health-status card widget at the top that consumes syncHealthProvider. Add a "Verify now" button that calls reliabilityRunnerProvider.checkNow().
lib/ui/screens/account_list_screen.dart Remove the inline health status tile (lines 120–157) and the "Verify sync health" menu item (line 226). Replace both with a single "Sync" navigation item that pushes SyncScreen.
Navigation/routing Update any route registrations that pointed to the old SyncLogScreen.
Strings / l10n Rename "Sync log" label to "Sync" (or "Sync status").

No changes needed to:

  • lib/data/db/database.dart
  • lib/core/sync/account_sync_manager.dart
  • lib/core/sync/reliability_runner.dart
  • lib/core/repositories/ or lib/data/repositories/
  • lib/di.dart
  • Any tests (data layer is unchanged)

Option C: Rename Only

Keep both screens but rename them to reduce confusion: e.g. "Sync history" and "Sync verification". Low effort, low risk, but the UX problem (two separate navigation destinations) remains.

Verdict: Addresses labelling but not the core UX issue. Only worth doing as a stop-gap.

Recommended Approach: Option B

The user confusion stems from having two separate navigation destinations for things that both say "sync". The solution is a single "Sync" screen with a clear visual hierarchy: health status at the top, history below. The underlying data models should stay separate because they store genuinely different things with different lifecycles.

Risks and Open Questions

  1. Screen real estate — if an account has many discrepancies, the health card could grow large. Consider collapsing detailed discrepancy info into an expandable section.
  2. Multiple accounts — today SyncScreen is per-account; health status is also per-account. The merge is straightforward as long as the screen stays scoped to one account. If there is ever a cross-account overview screen, the design needs revisiting.
  3. "Verify now" placement — moving the trigger from a menu item to an in-screen button makes it more discoverable; confirm this is desirable before implementing.
  4. Naming — "Sync" alone may be too generic if there are other sync-related screens in the future. "Sync status" or "Sync overview" are alternatives.
## Implementation Plan: Joining syncLog and syncHealth ### Current State **syncLog** and **syncHealth** serve fundamentally different roles: | Aspect | syncLog | syncHealth | |--------|---------|-----------| | Purpose | Audit trail of every sync cycle | Periodic verification that local cache matches server | | Trigger | After every sync cycle (continuous) | Hourly timer + manual (periodic) | | Storage | Last 100 entries per account (history) | Single row per account (current state only) | | Data | Emails fetched/skipped, bytes, errors, stack traces | Boolean health flag + per-mailbox discrepancy counts | | UI entry | Dedicated "Sync log" screen | Status indicator on account tile in AccountListScreen | **Key files:** - `lib/data/db/database.dart` lines 178–228 — `SyncLogs`, `SyncLogMailboxes`, `SyncHealth` tables - `lib/core/sync/account_sync_manager.dart` lines 238–251, 493–507 — writes syncLog after each IMAP/JMAP cycle - `lib/core/sync/reliability_runner.dart` — runs health verification hourly + on demand - `lib/ui/screens/sync_log_screen.dart` — full audit history UI - `lib/ui/screens/account_list_screen.dart` lines 120–157 — health status display - `lib/di.dart` lines 109–136 — `syncLogRepositoryProvider`, `syncHealthProvider`, `reliabilityRunnerProvider` --- ### Options #### Option A: Full Data Model Merge Collapse the two database tables into one concept. Each sync cycle entry would also carry health information; the periodic health check would produce an entry tagged as a "verification" type. **Drawbacks:** - The data shapes are genuinely different. syncLog keeps a rolling 100-entry history; syncHealth is a single mutable row. Merging them forces an awkward compromise: either pollute the log with nullable health columns or discard history for health checks. - The triggers are independent: syncLog fires after every sync cycle, syncHealth fires on a timer. Coupling them means a health check gap whenever syncing is paused, or spurious log entries whenever the health timer fires. - Schema migration required (Drift migration to drop/alter tables). - Increased complexity with no real UX benefit — the user confusion is about navigation, not underlying data. **Verdict:** Not recommended. --- #### Option B: Unified UI Entry Point (Recommended) Keep both data models exactly as-is, but merge the user-facing surface into a single "Sync" screen. The unified screen shows: 1. **Health banner at the top** — healthy/discrepancy status with last-verified timestamp and a manual "Verify now" button (currently scattered across the account tile menu). 2. **Sync history below** — the existing log list, exactly as today. This eliminates the user confusion ("two different sync things") without touching the data layer. **Files to change:** | File | Change | |------|--------| | `lib/ui/screens/sync_log_screen.dart` | Rename to `sync_screen.dart` / `SyncScreen`. Add a health-status card widget at the top that consumes `syncHealthProvider`. Add a "Verify now" button that calls `reliabilityRunnerProvider.checkNow()`. | | `lib/ui/screens/account_list_screen.dart` | Remove the inline health status tile (lines 120–157) and the "Verify sync health" menu item (line 226). Replace both with a single "Sync" navigation item that pushes `SyncScreen`. | | Navigation/routing | Update any route registrations that pointed to the old `SyncLogScreen`. | | Strings / l10n | Rename "Sync log" label to "Sync" (or "Sync status"). | **No changes needed to:** - `lib/data/db/database.dart` - `lib/core/sync/account_sync_manager.dart` - `lib/core/sync/reliability_runner.dart` - `lib/core/repositories/` or `lib/data/repositories/` - `lib/di.dart` - Any tests (data layer is unchanged) --- #### Option C: Rename Only Keep both screens but rename them to reduce confusion: e.g. "Sync history" and "Sync verification". Low effort, low risk, but the UX problem (two separate navigation destinations) remains. **Verdict:** Addresses labelling but not the core UX issue. Only worth doing as a stop-gap. --- ### Recommended Approach: Option B The user confusion stems from having two separate navigation destinations for things that both say "sync". The solution is a single "Sync" screen with a clear visual hierarchy: health status at the top, history below. The underlying data models should stay separate because they store genuinely different things with different lifecycles. ### Risks and Open Questions 1. **Screen real estate** — if an account has many discrepancies, the health card could grow large. Consider collapsing detailed discrepancy info into an expandable section. 2. **Multiple accounts** — today `SyncScreen` is per-account; health status is also per-account. The merge is straightforward as long as the screen stays scoped to one account. If there is ever a cross-account overview screen, the design needs revisiting. 3. **"Verify now" placement** — moving the trigger from a menu item to an in-screen button makes it more discoverable; confirm this is desirable before implementing. 4. **Naming** — "Sync" alone may be too generic if there are other sync-related screens in the future. "Sync status" or "Sync overview" are alternatives.
guettlibot commented 2026-05-28 03:55:01 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Planning complete. To resume this session:

claude --resume a79c3a50-630b-4b17-ab0b-169a4d0e403a --dangerously-skip-permissions
Planning complete. To resume this session: ``` claude --resume a79c3a50-630b-4b17-ab0b-169a4d0e403a --dangerously-skip-permissions ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels State/Planned
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#314