Gitpod Snapshotting: Uncertain Timing of Filesystem Sync During Workspace Restart

Goal

We want to ensure that a snapshot taken in a Gitpod workspace accurately captures the filesystem state so that a subsequent restoration yields the same data, including any in‑memory modifications that have not yet been flushed to disk.

Constraints & Uncertainty

Snapshots are created by Gitpod’s internal mechanism, but the exact moment when the snapshot engine flushes in‑memory buffers to the persisted volume is not documented. Additionally, there is no built‑in verification step that compares the snapshot contents with a reference state.

Specific Questions

1. Does Gitpod guarantee that all changes present in the running container’s memory at the time a snapshot is requested are persisted to the snapshot?
2. What tooling or API does Gitpod expose, if any, to programmatically validate that a restored workspace matches the snapshot’s contents, especially for files modified after the last Git commit?