Skip to content

checkpoint: preserve in-memory state of connections

Beniamino Galvani requested to merge bg/rollback-in-memory into main


If a connection is in-memory (i.e. has flag "unsaved"), after a checkpoint and rollback it can be wrongly persisted to disk:

  • if the connection was modified and written to disk after the rollback, during the rollback we update it again with persist mode "keep", which keeps it on disk;

  • if the connection was deleted after the rollback, during the rollback we add it again with persist mode "to-disk".

Instead, remember whether the connection had the "unsaved" flag set and try to restore the previous status.

However, this is not straightforward as there are 4 different possible states for the settings connection: persistent; in-memory only; in-memory shadowing a persistent file; in-memory shadowing a detached persistent file (i.e. the deletion of the connection doesn't delete the persistent file).

It would be difficult to implement the full rollback of the exact state for the last two cases because we would need to store information about the shadowed storage, restore the file and the nmmeta section in /run. Instead, if we need to roll back a in-memory-with-shadowed-file connection, promote it to a full persistent connection.

In other words, this commit fixes the behavior when the connection is in-memory only, and only adds a warning without changing behavior for in-memory connections shadowing a persistent one.


Please read before opening the merge request. In particular, check that:

  • the subject for all commits is concise and explicative
  • the message for all commits explains the reason for the change
  • the source is properly formatted
  • any relevant documentation is up to date
  • you have added unit tests if applicable
  • the NEWS file is updated when the change deserves to be mentioned, for example for new features, behavior changes, API deprecations, etc.


Edited by Beniamino Galvani

Merge request reports