Repository navigation
fix(cli): drop the lancedb finalization gate this process cannot trigger - #238
Merged
Merged
Conversation
`raven.cli.commands.run` hard-exited past interpreter finalization whenever lancedb's `LanceDBBackgroundEventLoop` thread was live. Nothing under `raven/` imports lancedb: it is a transitive dependency only, memory talks to everos over HTTP, and everos itself runs out-of-process. `torch`, named alongside it in the agent-loop comment, is neither declared nor imported either. The probe therefore returned False in every configuration and the branch was unreachable. Removed: the probe in `_exit.py`, the `if` it fed in `commands.py`, and the stale comment in `agent_commands.py` claiming the exit chokepoint covers that hazard. `flush_and_hard_exit` stays -- `tests/conftest.py` calls it on CI, where a fully green suite was observed exiting 139 on Linux. Its module docstring now describes that caller instead of the lancedb story, and says why the gate went. Deleting the whole `except SystemExit` block is behaviour-preserving: with the probe always False it reduced to `except SystemExit: raise`, and the exit-code normalization inside it only ever fed the hard-exit call, never the re-raised exception. Verified through the real console-script entry point, which `CliRunner` never reaches: `raven --version` 0, `skill get` with a missing argument 2, an unknown command 2, `status` 0, and an unparseable config still prints one clean line instead of a traceback. Suite goes 4655 -> 4653: the two tests that exercised the probe are gone, and the four covering `flush_and_hard_exit` remain. Co-authored-by: Claude (claude-opus-5) <noreply@anthropic.com>
arelchan
approved these changes
Jul 30, 2026
6 of 12 tasks
0xKT
added a commit
that referenced
this pull request
Jul 31, 2026
## Summary Bump the package version from 0.1.9 to 0.1.10 (patch release). 22 PRs merged since v0.1.9, no breaking changes. Features: - #260 feat(tui): list the providers that work, and the rest one level down - #252 feat(*): offer every supported provider in the onboarding picker - #251 feat(tools): read images with read_file, and fix four silent type-check bugs - #239 feat: add shell command approval flow - #217 feat: rework the TUI transcript into collapsible episodes - #220 feat(cli): nudge raven upgrade in the tui status bar when behind - #209 feat(providers): add MiniMax Global and CN OAuth Refactors: - #259 refactor(*): one answer to which credentials a provider needs - #249 refactor(providers): unify provider management on litellm The remaining PRs are fixes (#255, #256, #258, #253, #238, #226), test work (#236, #230, #224), docs (#250, #215, #200), and benchmark tooling (#207). ## Type - [ ] Fix - [ ] Feature - [ ] Docs - [ ] CI / tooling - [ ] Refactor - [x] Other ## Verification - [x] Relevant tests pass locally - [x] Relevant lint / type checks pass locally - [ ] User-facing docs or screenshots are updated when needed Bump is limited to `pyproject.toml` and `uv.lock` (`uv lock` sync). Local preflight covers the branch CI checks (commit lint, PR title and body lint, ruff, large-file gate). ## Risk - [x] Security impact considered - [x] Backward compatibility considered - [x] Rollback path is clear for risky changes Version-only change; no code or behavior change. Rollback is a revert of this commit. ## Related Issues N/A Co-authored-by: Claude (claude-opus-5[1m]) <noreply@anthropic.com>
KevinHuSh
pushed a commit
to KevinHuSh/Raven
that referenced
this pull request
Sep 14, 2026
…ger (EverMind-AI#238) ## Summary `raven.cli.commands.run` hard-exited past interpreter finalization whenever lancedb's `LanceDBBackgroundEventLoop` thread was live. That thread cannot exist in this process: lancedb is a transitive dependency only, nothing under `raven/` imports it, memory talks to everos over HTTP, and everos runs out-of-process. `torch`, named alongside it in the agent-loop comment, is neither declared nor imported either. The probe returned False in every configuration, so the branch was unreachable. Removed the probe in `_exit.py`, the `if` it fed in `commands.py`, and the comment in `agent_commands.py` claiming the exit chokepoint covers that hazard. `flush_and_hard_exit` stays: `tests/conftest.py` calls it on CI, where a fully green suite was observed exiting 139 on Linux. Its module docstring now describes that caller instead of the lancedb story, and records why the gate went. Deleting the whole `except SystemExit` block is behaviour-preserving. With the probe always False it reduced to `except SystemExit: raise`, and the exit-code normalization inside it only ever fed the hard-exit call -- never the re-raised exception. ## Type - [x] Others Dead-code removal in the CLI exit path, plus the two tests that exercised the removed probe. ## Verification `CliRunner` invokes the Typer app directly and never reaches `run()`, so the console-script entry point was smoked by hand: ``` raven --version -> 0 raven skill get (missing arg) -> 2 raven nosuchcmd -> 2 raven status -> 0 unparseable ~/.raven/config.json -> one clean warning line, no traceback ``` ``` uv run --all-extras pytest -q # 4653 passed, 13 deselected (4655 before: the two probe tests are gone, # the four covering flush_and_hard_exit remain) bash .claude/scripts/preflight_ci.sh # ALL PREFLIGHT CHECKS PASSED ``` Also grepped the whole repo, including `benchmarks/` and `scripts/`, for `lancedb_finalization_hazard` and `LanceDBBackgroundEventLoop`: no references remain. - [x] Relevant tests pass locally - [x] Relevant lint / type checks pass locally ## Risk - [x] Security impact considered - [x] Backward compatibility considered - [x] Rollback path is clear for risky changes The change is a deletion in a path no test host reaches, so the console-script smoke above is the real verification rather than the suite. If an embedded local-lancedb mode ever lands, the guard would need reinstating -- deliberately, and against a probe that can actually fire. ## Related Issues Closes EverMind-AI#232 Co-authored-by: Claude (claude-opus-5) <noreply@anthropic.com>
KevinHuSh
pushed a commit
to KevinHuSh/Raven
that referenced
this pull request
Sep 14, 2026
## Summary Bump the package version from 0.1.9 to 0.1.10 (patch release). 22 PRs merged since v0.1.9, no breaking changes. Features: - EverMind-AI#260 feat(tui): list the providers that work, and the rest one level down - EverMind-AI#252 feat(*): offer every supported provider in the onboarding picker - EverMind-AI#251 feat(tools): read images with read_file, and fix four silent type-check bugs - EverMind-AI#239 feat: add shell command approval flow - EverMind-AI#217 feat: rework the TUI transcript into collapsible episodes - EverMind-AI#220 feat(cli): nudge raven upgrade in the tui status bar when behind - EverMind-AI#209 feat(providers): add MiniMax Global and CN OAuth Refactors: - EverMind-AI#259 refactor(*): one answer to which credentials a provider needs - EverMind-AI#249 refactor(providers): unify provider management on litellm The remaining PRs are fixes (EverMind-AI#255, EverMind-AI#256, EverMind-AI#258, EverMind-AI#253, EverMind-AI#238, EverMind-AI#226), test work (EverMind-AI#236, EverMind-AI#230, EverMind-AI#224), docs (EverMind-AI#250, EverMind-AI#215, EverMind-AI#200), and benchmark tooling (EverMind-AI#207). ## Type - [ ] Fix - [ ] Feature - [ ] Docs - [ ] CI / tooling - [ ] Refactor - [x] Other ## Verification - [x] Relevant tests pass locally - [x] Relevant lint / type checks pass locally - [ ] User-facing docs or screenshots are updated when needed Bump is limited to `pyproject.toml` and `uv.lock` (`uv lock` sync). Local preflight covers the branch CI checks (commit lint, PR title and body lint, ruff, large-file gate). ## Risk - [x] Security impact considered - [x] Backward compatibility considered - [x] Rollback path is clear for risky changes Version-only change; no code or behavior change. Rollback is a revert of this commit. ## Related Issues N/A Co-authored-by: Claude (claude-opus-5[1m]) <noreply@anthropic.com>
LivXue
added a commit
that referenced
this pull request
Sep 18, 2026
LocalSkillCatalog auto-starts SkillFileWatcher, a daemon thread that parks inside the Rust watch() of watchfiles. Daemon status does not make process exit safe while the thread sits in native code: CPython runs Py_FinalizeEx under that call, and the process dies of SIGSEGV after every Python shutdown step has already succeeded. The crash also masks the command's real exit code. Measured on this tree with faulthandler armed. Every fault reports "<no Python frame>", so no Python code is on the stack: raven gateway SIGTERM exit -11, 5 of 5 runs raven tui PTY signal exit -11 raven agent normal exit exit 139 A controlled pair on the loop factory the TUI uses isolates the cause: build the loop and let the interpreter finalize, and the process exits 139; call stop_file_watcher() first and it exits 0. All three teardown chains now stop the watcher. The replay runner already did this for the same reason; these were the other long-lived owners. The call sits in each command's teardown rather than in AgentLoop.stop, whose other caller is the gateway generation swap: that path keeps the process running and must keep skill auto-refresh with it. Also drops a comment in agent_commands that pointed at the exit chokepoint in raven.cli.commands.run, a gate removed in #238. Co-authored-by: Claude (claude-opus-5[1m]) <noreply@anthropic.com>
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.
Summary
raven.cli.commands.runhard-exited past interpreter finalization whenever lancedb'sLanceDBBackgroundEventLoopthread was live. That thread cannot exist in this process: lancedb is a transitive dependency only, nothing underraven/imports it, memory talks to everos over HTTP, and everos runs out-of-process.torch, named alongside it in the agent-loop comment, is neither declared nor imported either. The probe returned False in every configuration, so the branch was unreachable.Removed the probe in
_exit.py, theifit fed incommands.py, and the comment inagent_commands.pyclaiming the exit chokepoint covers that hazard.flush_and_hard_exitstays:tests/conftest.pycalls it on CI, where a fully green suite was observed exiting 139 on Linux. Its module docstring now describes that caller instead of the lancedb story, and records why the gate went.Deleting the whole
except SystemExitblock is behaviour-preserving. With the probe always False it reduced toexcept SystemExit: raise, and the exit-code normalization inside it only ever fed the hard-exit call -- never the re-raised exception.Type
Dead-code removal in the CLI exit path, plus the two tests that exercised the removed probe.
Verification
CliRunnerinvokes the Typer app directly and never reachesrun(), so the console-script entry point was smoked by hand:Also grepped the whole repo, including
benchmarks/andscripts/, forlancedb_finalization_hazardandLanceDBBackgroundEventLoop: no references remain.Risk
The change is a deletion in a path no test host reaches, so the console-script smoke above is the real verification rather than the suite. If an embedded local-lancedb mode ever lands, the guard would need reinstating -- deliberately, and against a probe that can actually fire.
Related Issues
Closes #232