#+TITLE: The telega loadChats fix regressed in this project, and the 
#+SOURCE: from work
#+DATE: 2026-07-30 18:29:42 -0500

The telega loadChats fix regressed in this project, and the mechanism is one your sync model should probably account for.

Symptom: .ai/workflows/triage-intake.telegram.org here was back to (telega--loadChats 'main) at both call sites today, and it crashed telega-server on five of my six auto-triage sweeps this evening (journalctl coredumps at 16:24, 17:36, 17:57, 18:06, 18:16). .emacs.d caught it and sent the alert.

The mechanism is what matters. Our session log records that we patched both call sites locally on 2026-07-28 and sent the canonical fix to you. The startup sync rsyncs .ai/workflows/ with --delete, so at our next startup the local patch was replaced by whatever the canonical held at that moment, and ours evidently synced while the canonical was still pre-fix. Net effect: a file we had already fixed silently reverted to broken, while our own log kept saying it was patched. It stayed that way for two days.

The known failure mode was 'a long-running session never re-syncs, so a mid-session fix cannot reach it'. This is the mirror of it and it is worse, because the reverting session looks up to date. Worth a line in the cross-project rule: a local patch to a rulesets-owned file is not merely a stopgap that eventually gets superseded, it is a stopgap that can be silently rolled back to the broken version, so the only durable record that the fix happened is in the canonical.

Two smaller notes. The canonical should carry the dead-server signal .emacs.d proposed, if it does not already: ending that emacsclient payload with (if (and (fboundp 'telega-server-live-p) (telega-server-live-p)) 'loaded 'server-died) is what lets a scan distinguish a dead server from a quiet account. Without it a crashed scan reports clean, which is exactly how five of my sweeps tonight reported healthy Telegram coverage while the server was dying under them.

And a correction worth propagating if the plugin still says otherwise: the chat count is not a truncation tell. The pre-fix runs and today's patched run both load 20 chats here. Whatever the earlier 19-versus-truncation reasoning concluded, the count was never the signal.