Full config restore does not require restart after identity changes #132

New Issue

2026-10-27T09:34:41+01:00

adam commented

2026-10-27 09:34:41 +01:00

Summary

Restoring a full configuration backup on a new device can appear to leave the repeater on the newly generated identity, while the imported companion and room-server identities appear correctly in configuration.

Reproduction

Export a full backup with secrets from an existing repeater.
Import it during first-run setup on a new device.
Inspect the repeater identity and the imported companion/room-server entries without restarting the service.

Actual behavior

The imported identity keys are saved, but config_import reports restart_required: false when only repeater and/or identities changed. The running LocalIdentity, IdentityManager, helpers, and companion servers were created at startup and are not rebuilt by the config live-update path. This can make the active repeater identity look different from the restored key while the configuration screens show the imported values.

Expected behavior

A config import that changes repeater.identity_key or imports the identities section should report that a service restart is required so the restored identities become active.

Notes

The persisted repeater key survives YAML save/reload; the mismatch is between restored configuration and startup-owned runtime identity objects.

## Summary Restoring a full configuration backup on a new device can appear to leave the repeater on the newly generated identity, while the imported companion and room-server identities appear correctly in configuration. ## Reproduction 1. Export a full backup with secrets from an existing repeater. 2. Import it during first-run setup on a new device. 3. Inspect the repeater identity and the imported companion/room-server entries without restarting the service. ## Actual behavior The imported identity keys are saved, but `config_import` reports `restart_required: false` when only `repeater` and/or `identities` changed. The running `LocalIdentity`, `IdentityManager`, helpers, and companion servers were created at startup and are not rebuilt by the config live-update path. This can make the active repeater identity look different from the restored key while the configuration screens show the imported values. ## Expected behavior A config import that changes `repeater.identity_key` or imports the `identities` section should report that a service restart is required so the restored identities become active. ## Notes The persisted repeater key survives YAML save/reload; the mismatch is between restored configuration and startup-owned runtime identity objects.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#132