ilml-plugin-linkedin 1.10.0 → 1.11.0

package/CHANGELOG.md

@@ -1,8 +1,13 @@
 # Changelog
 
+## 1.11.0
+- **`sync-all` no longer gives up when a single thread misbehaves.** LinkedIn's inbox occasionally reacts to an automated search input by navigating the page away from `/messaging/` mid-sync. In v1.10.0 that single navigation killed the entire remaining queue — the run would abort on, say, item 1 of 67 and silently leave 66 unread. The thread loop now treats both thrown exceptions and verified-false returns the same way: log it, hand the thread to the sidebar fallback below, and keep moving. A bad thread costs that one slot, not the whole sync.
+- **`sync-all` now reaches conversations buried deep in the inbox.** LinkedIn only renders ~20 sidebar cards at a time and lazy-loads the rest on scroll. Older threads — including any conversation that hadn't received a recent message — sat outside that initial window, so the existing "click the card in the sidebar" path couldn't find them. When that fails, the sync now navigates back to `/messaging/`, scrolls the sidebar from the top, and reopens the thread once its card has been loaded. The happy path (top-of-inbox conversations found by direct click) is unchanged — only previously-failing threads pay the extra scrolling time.
+- No schema migration; existing data files unchanged.
+
 ## 1.10.0
 - **`sync-all` no longer crashes mid-run when the LinkedIn browser session freezes.** On a large inbox (2000+ conversations, 600+ threads to re-read), the browser tab would occasionally stall after an hour of scrolling and reading. A single stall used to abort the whole sync and lose the rest of the progress for that run — the user had to re-launch from scratch, often multiple times before any single run completed. The same auto-recovery that already protects `apply` (since v1.4.0) is now applied to `sync-all`: when the browser stalls, the script switches to a fresh tab and continues. In the inbox-scan phase that means restarting the scan from the top (up to 3 retries). In the thread-reading phase it means skipping that one problem thread (it'll be re-flagged on the next sync — nothing is lost) and continuing with the next. The `--backfill` mode (re-reads conversations stored with empty message lists) is covered by the same recovery. On large catch-up runs this is the difference between "finishes in one pass" vs. "needs 5-10 manual restarts."
-- **Session summary** reports the rec1overy count when it actually happened. Healthy runs print nothing new.
+- **Session summary** reports the recovery count when it actually happened. Healthy runs print nothing new.
 - Documentation: clarified the plugin's data-ownership intent and added a usage advisory pointing to LinkedIn's terms.
 - No schema migration; nothing on disk changed.