Repository navigation
[OMEGA-492] Redo an interrupted memory copy when a container holds omega-memory #388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
timur-ashkenov
merged 15 commits into
singnet:patch-to-v0.1.20
from
sassless:OMEGA-492-volume-in-use
Oct 23, 2026
Merged
Changes from all commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
679809b
[OMEGA-492] Cover a repeated copy while a container holds omega-memory
TossSky 1d72fea
[OMEGA-492] Remove the omega container before redoing an interrupted …
TossSky f7f7e5c
[OMEGA-492] Cover leftover copy containers and a memory import after …
TossSky de28d8a
[OMEGA-492] Clear leftover copy containers and let a memory import re…
TossSky b7adfab
[OMEGA-492] Cover leftover containers on other volumes and a failed i…
TossSky 922ba26
[OMEGA-492] Remove only leftover copy containers that hold the partly…
TossSky 0a2da89
[OMEGA-492] Cover keeping omega while another container holds the volume
TossSky b6de939
[OMEGA-492] Check other holders of the partly copied volume before re…
TossSky e201b5f
[OMEGA-492] Trigger CI
TossSky d4f1da4
[OMEGA-492] Cover imported memory over an interrupted copy and unread…
TossSky 7263f93
[OMEGA-492] Keep memory that is not a partial copy and stop an import…
TossSky 593d616
[OMEGA-492] Docs: Memory migrations warnings and recovery instructions
timur-ashkenov 788b52a
Merge branch 'patch-to-v0.1.20' into OMEGA-492-volume-in-use
timur-ashkenov 23058ba
[OMEGA-492] Docs: Move migration recovery guide to memory portability…
timur-ashkenov dcee926
[OMEGA-492] Docs: Move migration recovery guide to memory migration r…
timur-ashkenov File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,75 @@ | ||
| # Reference - Memory Migration | ||
|
|
||
| ## Recovering an interrupted memory migration | ||
|
|
||
| When upgrading from OmegaClaw, the launcher copies `omegaclaw-memory` to | ||
| `omega-memory`. Keep the terminal open and do not interrupt the launcher or | ||
| Docker until it reports `Memory copied`. Keep `omegaclaw-memory` until you have | ||
| checked that the agent remembers its previous data. | ||
|
|
||
| If the copy is interrupted, follow the appropriate path below before importing | ||
| memory or starting the agent again. Use the same image tag and launcher options | ||
| as in your original start command. | ||
|
|
||
| ### Retry the copy from OmegaClaw | ||
|
|
||
| Use this path only if `omega-memory` contains no imported memory or new agent | ||
| data that you need to keep. Retrying replaces this volume with a fresh copy of | ||
| `omegaclaw-memory`. | ||
|
|
||
| 1. List the containers holding the destination volume: | ||
|
|
||
| ```sh | ||
| docker ps -a --filter volume=omega-memory --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}' | ||
| ``` | ||
|
|
||
| 2. If the launcher reports `volume is in use` or names a leftover container, | ||
| stop and remove the identified container. Replace `CONTAINER_ID` with its | ||
| actual ID; do not remove unrelated containers or the source volume: | ||
|
|
||
| ```sh | ||
| docker rm -f CONTAINER_ID | ||
| ``` | ||
|
|
||
| This also applies to stopped containers. Copy containers started by the | ||
| v0.1.20 launcher have no migration label and need to be removed manually. | ||
| The updated launcher removes labelled copy containers and the `omega` | ||
| container automatically when retrying. | ||
|
|
||
| 3. Repeat your original `scripts/omega start ...` command, without | ||
| `--memory-import` or the `--only-history` and `--only-vector` flags. Wait for | ||
| `Memory copied`, then check the agent's memory. | ||
|
|
||
| ### Keep memory imported or used after the interruption | ||
|
|
||
| Do not retry the copy or run another import before preserving the current | ||
| `omega-memory` volume. Stop any remaining copy containers identified above and | ||
| stop the `omega` agent if it is running. Back up the destination volume before | ||
| changing migration state. | ||
|
|
||
| The v0.1.20 launcher could leave `.migration-started` in `omegaclaw-memory` | ||
| after a memory import. In particular, an `--only-vector` import can leave | ||
| `history.metta` unchanged. The updated launcher's history check cannot detect | ||
| this case: a normal start can delete the imported vectors and copy the old | ||
| memory over them. | ||
|
|
||
| If the import completed successfully and you want to keep the current memory, | ||
| clear only the stale migration marker before starting again: | ||
|
|
||
| ```sh | ||
| docker volume inspect omegaclaw-memory omega-memory | ||
| docker run --rm --entrypoint rm --volume omegaclaw-memory:/from \ | ||
| singularitynet/omega:v0.1.20 -f /from/.migration-started | ||
| ``` | ||
|
|
||
| Run the second command only if both volumes exist. Then repeat your normal | ||
| start command without `--memory-import` or the `--only-history` and | ||
| `--only-vector` flags. Clearing the marker keeps the current destination volume; | ||
| it does not finish a partial copy. If you are unsure whether | ||
| the import or copy completed, preserve both volumes and ask for help before | ||
| continuing. | ||
|
|
||
| If imported memory has already been overwritten, the old OmegaClaw volume | ||
| cannot recover that import. Restore it from the original import archive or a | ||
| backup of `omega-memory`. | ||
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we check whether memory was successfully imported after the interrupted migration, or preserve the existing volume before deleting it? A stale .migration-started marker could otherwise cause a normal start to discard valid imported memory. I see this is documented under Known limits - is this behavior intentional within the scope of OMEGA-492, or should we handle it here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 7263f93. The copy goes entry by entry, so a partial copy leaves
history.mettaempty, missing, or a prefix of the old file. Before redoing the copy,startcompares the two files. Ifomega-memoryholds anything else, such as an imported archive,startstops, leaves the volume and theomegacontainer as they are, and prints two commands: one clears the marker and keeps the memory, the other removesomega-memoryso the copy runs again.On
singularitynet/omega:v0.1.20both commands work, and a partly copied history is still copied again. The new cases are in d4f1da4.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, that covers the case where history has changed. What about --only-vector, where imported vector memory may change while history.metta stays the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timur-ashkenov Only for installs that went through v0.1.20 first. On this branch an import after an interrupted copy removes the partial volume and clears .migration-started (scripts/omega#L907-L918), so the history check never runs over imported memory. The v0.1.20 launcher kept the marker on import. An interrupted copy and an --only-vector import on v0.1.20, followed by a plain start with this launcher, would still remove the imported vectors. I'd cover that with the warning rather than extend the check.