TypingMind Cloud Sync (Modified)

⚠️ Disclaimer: This is a modified version of the original TypingMind Cloud Sync plugin. Full credit for the original architecture and codebase goes to Thomas (itcon-pty-au). You can find the original project here: https://github.com/itcon-pty-au/typingmind-cloud-backup.

🎯 Purpose

This fork exists to investigate and resolve specific reliability issues encountered in long-running browser sessions. The goal is to improve the resilience of the synchronization process, specifically addressing cases where sync operations silently cease to function after a period of activity, leading to data inconsistencies between the local TypingMind instance and the cloud storage (S3/R2).

🐛 Problem Statement

Users reported "zombie behavior" in the sync process:

1. Initial Load Works: When starting a fresh TypingMind instance, data loads correctly from the cloud.
2. Sync Stalls: After a period of normal operation, the automatic synchronization stops uploading new chats or updates.
3. Process Appears Active: The sync loop (interval) appears to be running, but no actual data transfer occurs.
4. No Crash: The plugin typically does not crash hard; it simply stops processing new changes efficiently.

🧪 Investigation & Hypotheses

To diagnose the root cause, four primary hypotheses were formulated:

1. The "Sync Lock" Deadlock (Implemented Fix ✅)

• Theory: The syncInProgress flag, used to prevent overlapping sync operations, might get stuck in a true state due to a network timeout, background tab throttling, or an unhandled exception during a sync cycle.
• Result: The autoSyncInterval checks this flag forever, sees it as true, and skips all future sync attempts.
• Fix: A "Watchdog Timer" was implemented in cloudsync2.js. If the sync lock remains active for more than 5 minutes, it is forcibly reset, allowing the cycle to restart.

2. Leader Election & Background Throttling

• Theory: Modern browsers aggressively throttle JavaScript timers in background tabs. The LeaderElection mechanism relies on setInterval, which might slow down significantly, causing the "Leader" tab to lose its status or fail to trigger the sync loop correctly.

3. IndexedDB Transaction Timeouts

• Theory: The data streaming logic involves complex async operations while iterating over an IndexedDB cursor. If the processing of a batch takes too long (e.g., due to crypto operations), the IndexedDB transaction might auto-commit or time out, silently killing the data stream.

4. Metadata Drift / Last Modified Logic

• Theory: A mismatch could occur between the actual cloud state and the local metadata. If the plugin believes a chat was uploaded (updating local metadata) but the upload actually failed or wasn't finalized in the cloud index, the logic might permanently skip that item in future checks because the timestamps appear identical.

🛠 Status

Currently, the fix for Hypothesis 1 (Sync Lock Deadlock) has been applied to cloudsync2.js. We are testing if this watchdog mechanism is sufficient to resolve the stalling issue in production environments.