← Back to PRs

#16989: fix(telegram): remove duplicate migration call during group->supergroup migration

by AI-Reviewer-QS open 2026-02-15 09:15 View on GitHub →
channel: telegram stale size: XS
## Summary - During Telegram group-to-supergroup migration, `migrateTelegramGroupConfig` was called twice: first on the freshly-loaded `currentConfig` (which is persisted to disk), then again on the stale startup `cfg` parameter (which is never saved). The second call was a copy-paste artifact that mutated a stale in-memory config object for no purpose. - Removed the redundant second call to `migrateTelegramGroupConfig({ cfg, accountId, oldChatId, newChatId })` at line 668 of `bot-handlers.ts`. ## Test plan - Existing `group-migration.test.ts` tests continue to pass (4/4 green), confirming the migration function itself is unaffected. - The removed line only mutated the stale `cfg` parameter which was never written to disk, so removing it has no behavioral change on persisted state. <!-- greptile_comment --> <h3>Greptile Summary</h3> Removes a redundant call to `migrateTelegramGroupConfig` in the `message:migrate_to_chat_id` handler in `bot-handlers.ts`. The handler already calls `migrateTelegramGroupConfig` with `currentConfig` (freshly loaded from disk) and persists it via `writeConfigFile(currentConfig)`. The removed line called the same function again with the stale `cfg` parameter (passed at startup), whose mutations were never saved — making it a no-op copy-paste artifact. - Removed duplicate `migrateTelegramGroupConfig({ cfg, accountId, oldChatId, newChatId })` call that mutated the stale startup `cfg` object without persisting it - No behavioral change: only `currentConfig` was ever written to disk; the stale `cfg` mutation had no effect - Existing tests (4/4 in `group-migration.test.ts`) continue to pass <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it removes dead code with no behavioral impact. - The change is a single-line removal of a clearly redundant function call. The removed call mutated the stale startup `cfg` parameter which was never persisted to disk (only `currentConfig` is written via `writeConfigFile`). The migration logic, persistence, and all logging remain intact. The change is well-scoped and verified by existing tests. - No files require special attention. <sub>Last reviewed commit: 9bf1cc6</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs