Repository navigation
fix(install): stop waiting when Lens can't start, and show what it logged in the web installer - #359
Merged
Merged
Conversation
…ith the logs and why Running the install line again over a microsandbox install could sit at "Waiting for the web app..." forever with no output: each check was a curl with no time limit, so a port that takes the connection but never answers held it for good, and the loop only printed when it gave up. - A rerun stops the running sandbox first (a minute to close the database, then forced), waits for its port to be free, and says who holds it if not. - Each check gives up after 5 seconds; the wait is time based (LENS_WAIT). - While waiting, it shows the steps the sandbox logs, and a line a minute. - It stops at once when a step fails or the sandbox stops, and on timeout, printing the last log lines and the reason (including a port that doesn't reach a Lens that is up inside the sandbox). - run.sh logs finer steps and a "Failed (exit N): step" line on error. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C5hhPc28UXdCfRpV9qP9it
…ow what Lens logged in the web installer install.sh lists the sandbox's own steps as steps (the web installer shows them as they come), stops waiting at once when run.sh has started the same part of Lens three times, and the web installer shows the last lines Lens logged under the reason instead of only a command to run. CI breaks the database keys on purpose and checks that the wait ends with the API's own words. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
…nd shows why Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
Closed
17 of 22 tasks
…teps without their [lens] prefix in CI Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
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: when Lens couldn't start in its microsandbox, the installer (and the web installer on a Mac) sat at "Waiting for the web app..." for 30 minutes and then said only "Lens didn't answer within 30 minutes. See what happened: ... msb logs -f lens". Running the line again over a running install could also hang there with no output.
After: the installer lists the sandbox's own steps as they happen (installing packages, building, starting the database), and stops waiting as soon as a step fails, the sandbox stops, or a part of Lens keeps stopping (run.sh has started it three times). It then prints the last lines Lens logged and the reason, and the web installer shows those lines under the reason. For #358's case, that means "Lens's API keeps stopping in its microsandbox" within a minute or two, with the API's own
cannot open SurrealDB ... SURREAL_USER/SURREAL_PASS don't matchline on screen.Motivation and Context
This takes over #327, which stalled, and builds on it. #327's commit is kept as is (rebased onto main); the second commit adds the crash-loop check and the log tail in the web installer.
How:
lenssandbox first (msb stop -t 60, then-f) and waits for its port, naming what holds it (lsof). Each check gives up after 5 seconds, and the wait is time based (LENS_WAIT). New[lens]lines are shown while waiting. It fails at once on a[lens] Failedline or when the sandbox is not running twice in a row. On timeout it checks inside the sandbox whether only the port is the problem, and prints the last 40 log lines.run.shlogs finer steps and aFailed (exit N): stepline on error.saylines, so the web installer lists them as steps. Three[lens] NAME stopped; starting it againlines for the same part end the wait, with a reason that names the part (database, API, web app, job worker).lens_installer.pykeeps the lines after "The last lines Lens logged:" (log_tail) and returns them astail, andpage.htmlshows them under the error.Steps to reproduce (if appropriate):
Install with
LENS_BACKEND=microsandbox, then changeSURREAL_PASSin~/lens/.envand run the line again. The microsandbox CI job does exactly that: it checks for the "keeps stopping" reason and the API's own words, then restores.envand reinstalls. It also keeps #327'sLENS_WAIT=8check and #358's reinstall-after-delete check.Types of changes
!in the title)Checklist:
docs/accordingly (docs/microsandbox.md,docs/get-started.md).## UnreleasedinCHANGELOG.md.Done questions (AGENTS.md)
lsofis optional, used only to name what holds a port).LENS_WAITis optional and install-time, like the other settings at the top ofinstall.sh.lenscollides when two install folders are used.Closes #327.
🤖 Generated with Claude Code
https://claude.ai/code/session_01G7Lm1fFWPE5g9CMRUJxeSL
Generated by Claude Code