anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #3123] Fix/session migration #10543

New Issue
Closed
opened 2026-02-16 18:15:13 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:15:13 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/3123

State: closed
Merged: No

Summary

This pull request resolves a critical bug that caused sessions to appear lost when the application was launched from a different directory than the one in which the sessions were created. It introduces a global session storage mechanism and a lazy migration strategy to seamlessly transition existing sessions without data loss.

Problem

Previously, session data was stored in a directory scoped to a project.id, which was derived from the current working directory. This meant that if a user started the application in /project-a and created sessions, those sessions would not be visible when the application was later started in /project-a, as a partial migration had already taken place. This gave the impression that the sessions had been deleted, leading to a confusing and frustrating user experience.

The issue was compounded when attempting to interact with a session from a different directory, which would result in an ENOENT: no such file or directory error, as the application would look for the session file in the wrong location.

Solution

This PR implements a robust, backwards-compatible solution by refactoring the session storage logic:

  1. Global Session Storage: All new sessions are now created in a centralized session/global/ directory within the application's storage path, removing the dependency on the project's directory.

  2. Lazy Migration for Existing Sessions: To handle sessions created before this change, a lazy migration strategy has been implemented in the get, update, and remove functions. When an operation is performed on a session:

    • The system first looks for the session file in the new session/global/ directory.
    • If not found, it searches the old project-specific directory (session/<project_id>/).
    • Upon finding the session in the old location, it is automatically and transparently moved to the new global directory before the operation proceeds.

  3. Backwards-Compatible Listing: The list function has been updated to read sessions from both the new global directory and any existing project-specific directories, ensuring that all relevant sessions for the current context are displayed, regardless of where they are stored.

  4. Load Last Session on Startup: A client-side improvement was also included to automatically load the most recent session on application startup, improving usability.

This approach ensures that all existing data is preserved and migrated seamlessly over time, while all new data adheres to the more robust global storage model.

Testing

This fix has been manually tested by:

  1. Starting the application and creating a new session.
  2. Closing the application and restarting it.
  3. Verifying that the session created in step 1 is correctly listed and can be opened.
  4. Verifying that interacting with the session (sending a prompt) works as expected and does not produce an ENOENT error.
  5. Verifying that old sessions created with the previous storage mechanism are also listed and are automatically migrated upon interaction.
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/3123 **State:** closed **Merged:** No --- ## Summary This pull request resolves a critical bug that caused sessions to appear lost when the application was launched from a different directory than the one in which the sessions were created. It introduces a global session storage mechanism and a lazy migration strategy to seamlessly transition existing sessions without data loss. ## Problem Previously, session data was stored in a directory scoped to a `project.id`, which was derived from the current working directory. This meant that if a user started the application in `/project-a` and created sessions, those sessions would not be visible when the application was later started in `/project-a`, as a partial migration had already taken place. This gave the impression that the sessions had been deleted, leading to a confusing and frustrating user experience. The issue was compounded when attempting to interact with a session from a different directory, which would result in an `ENOENT: no such file or directory` error, as the application would look for the session file in the wrong location. ## Solution This PR implements a robust, backwards-compatible solution by refactoring the session storage logic: 1. **Global Session Storage:** All new sessions are now created in a centralized `session/global/` directory within the application's storage path, removing the dependency on the project's directory. 2. **Lazy Migration for Existing Sessions:** To handle sessions created before this change, a lazy migration strategy has been implemented in the `get`, `update`, and `remove` functions. When an operation is performed on a session: * The system first looks for the session file in the new `session/global/` directory. * If not found, it searches the old project-specific directory (`session/<project_id>/`). * Upon finding the session in the old location, it is **automatically and transparently moved** to the new global directory before the operation proceeds. 3. **Backwards-Compatible Listing:** The `list` function has been updated to read sessions from both the new global directory and any existing project-specific directories, ensuring that all relevant sessions for the current context are displayed, regardless of where they are stored. 4. **Load Last Session on Startup:** A client-side improvement was also included to automatically load the most recent session on application startup, improving usability. This approach ensures that all existing data is preserved and migrated seamlessly over time, while all new data adheres to the more robust global storage model. ## Testing This fix has been manually tested by: 1. Starting the application and creating a new session. 2. Closing the application and restarting it. 3. Verifying that the session created in step 1 is correctly listed and can be opened. 4. Verifying that interacting with the session (sending a prompt) works as expected and does not produce an `ENOENT` error. 5. Verifying that old sessions created with the previous storage mechanism are also listed and are automatically migrated upon interaction.
yindo added the pull-request label 2026-02-16 18:15:13 -05:00
yindo closed this issue 2026-02-16 18:15:13 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#10543
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?