Repository navigation
fix(install): start a fresh microsandbox install on its own volume when an earlier install's data is there - #358
Merged
Conversation
…en an earlier install's data is there A first install (no .env yet) made new keys but mounted the lens-data volume an earlier install left behind, say after ~/lens was deleted. Its database opens only with that install's keys, so the API stopped at every start and the install waited 30 minutes for a web app that never came up. A first install now leaves such a volume as it is and starts on lens-data-2 (or the next free name), kept in .env as LENS_VOLUME; a volume with no database yet is used as it is. CI deletes the install folder after an install and checks that the next one comes up. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
adeelahmad
added a commit
that referenced
this pull request
Oct 14, 2026
…atabase to a volume of its own (#360) A reinstall made before #358, after ~/lens was deleted, wrote new keys but kept the earlier install's lens-data volume, and every update after it kept both: the API stopped at every start with "SURREAL_USER/SURREAL_PASS don't match". run.sh now signs in with .env's credentials right after the database starts; on a 401 it says "Another install's database", closes the database and stops. install.sh, seeing that line, moves Lens to a volume of its own (kept in .env as LENS_VOLUME), rewrites .lens-sandbox and starts again, once. Keys and the earlier volume are kept. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016M1M7EXU6uJVnqfp77L19k
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Requested by Adeel · project thread
Description
Before: installing Lens in a microsandbox again after
~/lenswas deleted (the web installer on a Mac, in this case) stopped at "Waiting for the web app..." and after 30 minutes said only "Lens didn't answer within 30 minutes".After: that install leaves the earlier install's data volume as it is, starts on one of its own (
lens-data-2, or the next free name) and comes up. It says so while installing, and how to remove the old volume.Motivation and Context
The
lens-datavolume outlives the install folder, but its database opens only with the keys in that folder's.env(SurrealDB keeps the root user it was first started with). A first install writes new keys, so it mounted the old volume with keys that can't open it: the API stopped at every start (cannot open SurrealDB ... SURREAL_USER/SURREAL_PASS don't match) and install.sh waited out its 30 minutes.How:
install.shnotes when it writes a new.env. Then, ifmsb volume lshaslens-dataand it may hold a database, it picks the next freelens-data-N. A volume it can see has no database (empty, or run.sh's tools and nosurreal/lens.db) is used as it is, so a first install that failed before Lens ever started keeps its downloads..envasLENS_VOLUME, so later runs,.lens-sandbox, the LaunchAgent and the systemd unit use the same volume. Existing installs getLENS_VOLUME=lens-dataon their next run: nothing changes for them..envback uses it again;msb volume rm lens-dataremoves it.Steps to reproduce (if appropriate):
Install with
LENS_BACKEND=microsandbox, delete the install folder, install again. The microsandbox CI job now does exactly that (with an emptylens-data-2already there, so the "no database" branch is checked too) and checks that Lens answers, the old volume is kept, and a rerun keeps the new one.Types of changes
!in the title)Checklist:
docs/accordingly (docs/microsandbox.md).## UnreleasedinCHANGELOG.md.Done questions (AGENTS.md)
LENS_VOLUMEis install bookkeeping likeLENS_DIR).lens-data(written to.envasLENS_VOLUME); no stored-data change.🤖 Generated with Claude Code
https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
Generated by Claude Code