8000 fix(install): move a microsandbox install whose keys don't open its database to a volume of its own by adeelahmad · Pull Request #360 · adeelahmad/lense · GitHub
[go: up one dir, main page]
Skip to content

fix(install): move a microsandbox install whose keys don't open its database to a volume of its own - #360

Merged
adeelahmad merged 3 commits into
mainfrom
claude/project-thread-snty5h
Oct 14, 2026
Merged

fix(install): move a microsandbox install whose keys don't open its database to a volume of its own#360
adeelahmad merged 3 commits into
mainfrom
claude/project-thread-snty5h

Conversation

@adeelahmad
@adeelahmad adeelahmad commented Oct 14, 2026
Copy link
Copy Markdown
Owner

Requested by Adeel · project thread

Description

Before: running the install line to update a microsandbox install could end with the API and worker stopping at every start: cannot open SurrealDB ... SURREAL_USER/SURREAL_PASS don't match the user this database was created with. Running the line again changed nothing.

After: each start, the sandbox checks that the keys in .env open the database. When they don't, it says Another install's database, closes the database and stops. The install line then moves Lens to a volume of its own (lens-data-2, or the next one with no database), saves it in .env as LENS_VOLUME, and starts Lens there. The keys and the earlier volume are left as they are.

Motivation and Context

The update path keeps .env's secrets; CI's "Running it again ... keeps the secrets" step already proves that. The mismatch comes from earlier. A reinstall made before #358 (after ~/lens was deleted) wrote new keys but mounted the earlier install's lens-data, whose database only that install's keys open. #358 stopped a new first install from landing there, but an install already in that state has an .env with no LENS_VOLUME, so every update mounts lens-data again and crash-loops. That is the state Adeel's Mac is in. The old data can't be opened with the new keys anyway: ARCHIVE_SECRET_KEY wraps every namespace's data key. A volume of its own is the only way such an install comes up, and the earlier volume stays for the .env that made it.

How: microsandbox/run.sh POSTs .env's credentials to SurrealDB's /signin right after it is ready. A 401 means other keys; any other answer is retried, then ignored, so the API reports it as before. install.sh factors the #358 volume choice into own_volume and the .lens-sandbox writer into write_sandbox. On the sandbox's line it calls other_volume once, which picks a free volume, rewrites .lens-sandbox (also used at boot), and starts again with the wait reset.

Steps to reproduce (if appropriate):

Reproduced locally with SurrealDB 3.2.4: a database created with --pass AAA and started with --pass BBB logs "existing root users were found. The root user 'root' will not be created", and /signin with BBB answers 401 "There was a problem with authentication". The run.sh check in a harness exits 3 with the new line and closes the database cleanly; with the right keys it carries on.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (shellcheck clean on run.sh and install.sh).
  • I added or updated tests: a new microsandbox CI step gives an install new keys and no LENS_VOLUME (as on Adeel's Mac), and checks that the line moves it to lens-data-3, keeps its keys and the other volumes, and stays there on the next run. The "keeps stopping" step now breaks ACCESS_SECRET_KEY, because wrong database keys no longer crash-loop.
  • My change requires documentation updates, and I have updated docs/ accordingly (docs/microsandbox.md, How it runs).
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md.

Done questions (AGENTS.md)

  • Goal: delivers what the user wanted, merged on green CI. (Pending CI.)
  • Agents: n/a, install-time behaviour; the web app's upgrade agent and Lens.app run the same install.sh.
  • Zero setup: recovery is the same install line, with no .env edit.
  • Fewest clicks and keystrokes: nothing to answer.
  • Configurable: n/a, no new setting (LENS_VOLUME already existed).
  • Light: one localhost request per start.
  • Private and secure: no new surface; the sign-in check is on the sandbox's own localhost, and the password goes through stdin, not the command line.
  • Cost: n/a, no model calls.
  • User decides: nothing is deleted. The earlier volume is kept, and the output says how to go back to it (its .env plus LENS_VOLUME) or remove it. An install whose keys open its database behaves as before.
  • Upgrades: this is the upgrade fix; stored data isn't reshaped.
  • Honest: the docs and changelog describe only this behaviour.
  • Tests, docs and generated files updated.
  • Open standards; no new dependencies (python3 and curl are already in the sandbox).
  • Result reported with evidence; refine later: the Docker backend has the same trap if ~/lens is deleted without down -v (its named volumes outlive the folder). Also, setenv rewrites .env with the user's umask on updates, so an updated .env can become 0644; that goes in a separate PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_016M1M7EXU6uJVnqfp77L19k

Generated by Claude Code

@claude
fix(install): move a microsandbox install whose keys don't open its d…
03f2c27 
…atabase to a volume of its own

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". #358 only stopped a new first install from landing there.

run.sh now signs in with .env's SURREAL_USER/SURREAL_PASS right after the database starts. When SurrealDB answers
401, it says "Another install's database", closes the database and stops instead of starting the API again and
again. install.sh, seeing that line, moves Lens to a volume of its own (the first lens-data-N with no database, as a
first install does), keeps it in .env as LENS_VOLUME, rewrites .lens-sandbox and starts again, once. The keys and
the earlier volume are left as they are.

CI: the "keeps stopping" check breaks ACCESS_SECRET_KEY instead of SURREAL_PASS, and a new step gives an install new
keys and no LENS_VOLUME, as on Adeel's Mac, and checks that the line moves it to lens-data-3 and stays there.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016M1M7EXU6uJVnqfp77L19k
@adeelahmad adeelahmad self-assigned this Oct 14, 2026
claude added 2 commits October 14, 2026 10:35
@claude
Merge remote-tracking branch 'origin/main' into claude/project-thread…
247e84c 
…-snty5h

# Conflicts:
#	CHANGELOG.md
@claude
Merge origin/main into claude/project-thread-snty5h
0dcbadc 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016M1M7EXU6uJVnqfp77L19k
@adeelahmad
adeelahmad merged commit 1525d4d into main Oct 14, 2026
16 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-snty5h branch October 14, 2026 11:26
@adeelahmad adeelahmad mentioned this pull request Oct 14, 2026
Merged
18 of 22 tasks
adeelahmad pushed a commit that referenced this pull request Oct 14, 2026
@claude
Merge origin/main: bring in #346, #360 and #361
fc127c8 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014pKRz6HkdQ7hTqEbpnyhYo
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@adeelahmad adeelahmad

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@adeelahmad @claude
0