fix(composables): Correct inverted logic in version check causing infinite loop thus OOM#421
Conversation
…inite loop thus OOM Corrects the `satisfiesVersionBy` logic in the `useVersionedLocalStorage` composable. The previous implementation (`v !== '1.0.2'`) was inverted, causing it to return `false` for the valid version. This triggered the `onVersionMismatch` handler, which reset the data, re-triggered the `watch` effect, and resulted in an infinite recursive update loop, crashing the application. The condition has been changed to `v === '1.0.2' to correctly validate the version and prevent the loop. I though this is tauri fault, but kek just silly mistake Fix moeru-ai#414 moeru-ai#375 moeru-ai#400
✅ Deploy Preview for airi-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for airi-vtuber ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![gemini-code-assist[bot]](https://avatars.gh.lumenfield.work/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @skirkru, 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 resolves a critical bug that caused the application to crash due to an infinite recursive update loop. The issue stemmed from an incorrectly implemented version validation logic within the useVersionedLocalStorage composable. By correcting an inverted condition, the change ensures proper data version validation, preventing continuous data resets and stabilizing the application.
Highlights
- Bug Fix: Infinite Loop and OOM: Addresses a critical bug where an inverted version validation logic in
useVersionedLocalStorageled to an infinite recursive update loop, causing out-of-memory errors and application crashes. - Logic Correction: Corrected the
satisfiesVersionByfunction fromv !== '1.0.2'tov === '1.0.2', ensuring proper validation of stored data versions. - Impact: Prevents erroneous triggering of data resets and resolves the continuous cycle of updates, stabilizing the application.
Using Gemini Code Assist
The 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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.
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.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request effectively resolves a critical bug that was causing an infinite loop and subsequent memory exhaustion. The fix, which corrects the inverted logic in the satisfiesVersionBy version check, is accurate and directly addresses the root cause described. My review includes a suggestion to refactor the duplicated versioning configuration to improve long-term maintainability, which can be handled in a follow-up.
| { | ||
| name: 'tamagotchi.settings.pages.themes.window-shortcuts.toggle-move.label', | ||
| shortcut: useVersionedLocalStorage('shortcuts/window/move', 'Shift+Alt+N', { defaultVersion: '1.0.2', satisfiesVersionBy: v => v !== '1.0.2', onVersionMismatch: () => ({ action: 'reset' }) }), // Shift + Alt + N | ||
| shortcut: useVersionedLocalStorage('shortcuts/window/move', 'Shift+Alt+N', { defaultVersion: '1.0.2', satisfiesVersionBy: v => v === '1.0.2', onVersionMismatch: () => ({ action: 'reset' }) }), // Shift + Alt + N |
There was a problem hiding this comment.
This change correctly fixes the critical infinite loop bug. Well done for spotting the inverted logic!
For future maintainability, you might consider refactoring the duplicated versioning options. The object { defaultVersion: '1.0.2', satisfiesVersionBy: v => v === '1.0.2', onVersionMismatch: () => ({ action: 'reset' }) } is repeated for each shortcut.
You could extract this to a constant at the top of the defineStore callback:
const shortcutVersionOptions = {
defaultVersion: '1.0.2',
satisfiesVersionBy: (v: string) => v === '1.0.2',
onVersionMismatch: () => ({ action: 'reset' as const }),
};And then reuse it for each shortcut:
shortcut: useVersionedLocalStorage('shortcuts/window/move', 'Shift+Alt+N', shortcutVersionOptions),This would make it easier to update the versioning logic in one place in the future. Since this is a broader refactoring that affects lines outside the current changes, it can be addressed in a follow-up PR.
|
Already improved from 21b3307 with universal model selector. |
|
Oh sorry I misunderstood this Pull Request. Indeed helpful, thanks. |
|
@nekomeowww I checked your commit 21b3307, that does not solve the issue |
|
Oh lol, that comment up when I typing |
…inite loop thus OOM (moeru-ai#421) Corrects the `satisfiesVersionBy` logic in the `useVersionedLocalStorage` composable. The previous implementation (`v !== '1.0.2'`) was inverted, causing it to return `false` for the valid version. This triggered the `onVersionMismatch` handler, which reset the data, re-triggered the `watch` effect, and resulted in an infinite recursive update loop, crashing the application. The condition has been changed to `v === '1.0.2' to correctly validate the version and prevent the loop. I though this is tauri fault, but kek just silly mistake Fix moeru-ai#414 moeru-ai#375 moeru-ai#400
…inite loop thus OOM (moeru-ai#421) Corrects the `satisfiesVersionBy` logic in the `useVersionedLocalStorage` composable. The previous implementation (`v !== '1.0.2'`) was inverted, causing it to return `false` for the valid version. This triggered the `onVersionMismatch` handler, which reset the data, re-triggered the `watch` effect, and resulted in an infinite recursive update loop, crashing the application. The condition has been changed to `v === '1.0.2' to correctly validate the version and prevent the loop. I though this is tauri fault, but kek just silly mistake Fix moeru-ai#414 moeru-ai#375 moeru-ai#400
2 participants
Description
Fixed Memory Leak by Endless Loop, Fix #414, #375, #400
Summary
This commit resolves a critical bug that caused the application to crash due to an infinite recursive update loop. The issue originated in the
useVersionedLocalStoragecomposable, where the version validation logic was incorrectly implemented.Problem
The
satisfiesVersionByfunction was configured with an inverted condition (v !== '1.0.2'). This logic incorrectly identified the current, valid data version as incompatible. As a result, theonVersionMismatchhandler was perpetually triggered, leading to a continuous cycle of data resets and component updates that ultimately exceeded Vue's maximum recursion depth and crashed the application.Solution
The logical condition in the
satisfiesVersionByfunction has been corrected to `v === '1.0.2'. This ensures that the stored data's version is properly validated, preventing the erroneous triggering of the data reset mechanism and resolving the infinite loop.My Comment
I thought this was a Tauri fault, but it turned out to be a silly mistake.