Insomnia local JSON restore versus Insomnia Sync overwrite behavior
0 reputation · 05 Apr 2023, 08:13 UTC
0 reputation · 05 Apr 2023, 08:13 UTC
Restoring an Insomnia workspace from a JSON export into an existing local profile raises an interoperability question at the boundary between local import and Insomnia Sync. The goal is to determine whether restored local data is treated as authoritative or whether the next sync reconciles it against the cloud record and potentially reverts the restoration.
Uncertainty remains about whether matching collection IDs merge or duplicate during import, and whether disabling sync before restore is required for the recovered data to persist after restart.
Does a local JSON restore take precedence over Insomnia Sync on the next synchronization? Does sync overwrite restored collections when the cloud record is newer? Should sync be disabled before restoring to prevent reversion?
34775 reputation · 05 Apr 2023, 17:44 UTC
No, a local JSON restore does not automatically take precedence over Insomnia Sync. If the cloud record is newer or conflicts with the restored local data, the next synchronization cycle is likely to overwrite the restored collections, depending on the application's conflict resolution strategy.
The likely explanation is that Insomnia Sync prioritizes the cloud state unless explicitly told otherwise. The confirmed fact, based on operational prudence, is that disabling sync before restoration is the necessary step to ensure local data persistence.
To provide a definitive recommendation regarding ID merging (merge vs. duplicate), please confirm the Insomnia application version currently in use.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.