Summary

Upgrading 2026.6.11 → 2026.7.1: 6.11 had long since imported our legacy plugin-state sidecar (plugin-state/state.sqlite) into shared state, but never retired the file (no .migrated rename, unlike the telegram-dir sidecars). 7.1's migration gate sees "sidecar present AND target namespace non-empty", declares the migration unclean, and refuses to report ready. There is no clean upgrade path from that state, and every retry re-trips the gate.

The sidecar was 100% redundant

The sidecar held 71 rows (67 telegram.message-cache, 3 telegram.topic-name-cache, 1 telegram.bot-info-cache; file last written weeks before the upgrade). Comparing against shared state (plugin_state_entries):

• 67 rows byte-identical in shared state
• 4 rows where shared state was newer
• 0 rows unique to the sidecar

Nothing held the file open. This is "import finished long ago, source never retired", not a real conflict.

The error message points at the wrong thing

The boot error cited a key of the form …:<chat-id>:162 as "already existed in shared state". That key is not in the sidecar at all; it was written to shared state moments earlier by the live 6.11 gateway (message-cache rows are written continuously per message). So the guard is tripping on "target namespace non-empty", and the message sent us diagnosing a data conflict that does not exist.

Why the operator cannot get out cleanly

• A live gateway writes fresh message-cache rows continuously, so the target namespace can never be empty.
• 6.11's doctor does not retire the sidecar.
• Combined with the SIGSEGV failure path (gateway: startup-migration failure path exits with SIGSEGV (139) instead of a clean non-zero exit, causing supervisor crash loops #109831), the result is a production crash loop with no supported remediation. We hand-archived the sidecar files off the state dir to recover.

Expected

When every sidecar row is already present in shared state, identical or older, treat the migration as satisfied: retire the sidecar (rename .migrated, matching the telegram-dir convention) and boot. If real conflicts exist, name the actual conflicting sidecar rows, not a key from the live namespace.