fix(core): prevent ENOENT crash due to proper-lockfile race condition#25885
fix(core): prevent ENOENT crash due to proper-lockfile race condition#25885spencer426 wants to merge 5 commits into
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical startup crash caused by a race condition in the proper-lockfile package. By providing explicit handlers for compromised locks, the application now safely manages scenarios where a lock directory is removed while a background status check is still pending, preventing unhandled exceptions and improving overall CLI stability under load. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
Size Change: +349 B (0%) Total Size: 33.9 MB
ℹ️ View Unchanged
|
gemini-cli
Bot
added
the
priority/p0
spencer426
force-pushed
the
unable-to-start
branch
2 times, most recently
from
a24be6c to
cf3a01e
Compare
spencer426
force-pushed
the
unable-to-start
branch
2 times, most recently
from
4adfcca to
d80fccd
Compare
spencer426
force-pushed
the
unable-to-start
branch
from
d80fccd to
bf4017b
Compare
|
Hi there! Thank you for your interest in contributing to Gemini CLI. To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'. This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
|
This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding. |
2 participants
Summary
This PR fixes a critical startup crash where the CLI exits with an unhandled
exception:
Error: ENOENT: no such file or directory, stat '.../.gemini/projects.json.lock'.This addresses the bug where the CLI occasionally hangs or crashes on launch,
particularly when multiple commands are run in quick succession or under heavy
concurrent load.
Details
The crash is caused by an internal race condition within the
proper-lockfilepackage.
When we acquire a lock (e.g., for
projects.jsonortrusted_folders.json),proper-lockfilesets up a background interval (setTimeout) to periodicallyupdate the lock directory's
mtimeso that the lock doesn't become "stale".This update process calls
fs.staton the.lockdirectory.The race condition occurs if the CLI finishes its task and releases the lock
(which deletes the
.lockdirectory) at the exact moment the backgroundstatoperation is pending in the event loop. When the
statcallback eventuallyfires, the directory is already gone, yielding an
ENOENTerror.By default,
proper-lockfiletreats anENOENTduring an update as a"compromised lock" and triggers its
onCompromisedhandler. The defaultimplementation of this handler is
(err) => { throw err; }, which results in anunhandled asynchronous exception that crashes the entire Node process.
This PR implements explicit
onCompromisedhandlers anywhere we calllock()(specifically in
ProjectRegistryandtrust.ts). By providing a customcallback that catches and logs (or safely ignores) the
ECOMPROMISEDevent, weprevent
proper-lockfilefrom throwing the unhandled exception.Related Issues
Fixes #1631
How to Validate
npm run test -w packages/coreto ensure no regressions in configurationor trust management.
statcall and callingrelease()manually perfectly reproduces the crashwithout the fix, and successfully catches the error with the fix.
Pre-Merge Checklist