fix: event-driven saveOnEmpty to prevent data loss on fast shutdown#89
fix: event-driven saveOnEmpty to prevent data loss on fast shutdown#89
Conversation
) Replace the 30-second polling PFH with an immediate check inside the HandleDisconnect event handler. With persistent=0, the server could terminate before the PFH fires, losing the recording entirely. Also remove dead arguments from :MISSION:SAVE: — the extension already has all mission/world data from :MISSION:START: at init time and ignores these args.
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 enhances the robustness of the recording system by addressing a critical data loss scenario during server shutdowns. It transitions the Highlights
Changelog
Activity
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. 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
|
There was a problem hiding this comment.
Code Review
This pull request effectively addresses a potential data loss issue with saveOnEmpty on fast-shutdown servers by replacing the 30-second polling mechanism with an event-driven check in the HandleDisconnect event handler. This ensures that a save is triggered immediately when the last player leaves. Additionally, the removal of unused and problematic arguments from the :MISSION:SAVE: extension call is a good cleanup that prevents confusion and fixes a bug related to reading worldName at an incorrect time. The changes are logical and well-implemented. I have one minor suggestion for a small performance and robustness improvement in the player count check.
Summary
HandleDisconnect. When the last player disconnects, the save triggers instantly instead of waiting up to 30 seconds for the next poll — preventing data loss whenpersistent=0causes the server to shut down before the PFH fires.:MISSION:SAVE:: The extension ignores all arguments passed in this command (worldName, missionName, author, captureDelay, endFrameNumber, saveTag) — it already has this data from:MISSION:START:at init time. Removes the stale reads to prevent future confusion.Reported by Darkstar2135: with
saveOnEmpty+persistent=0, the world/map name occasionally saved incorrectly (~15%) becauseworldNamewas read live at save time when the world could already be unloading.Test plan