fix: add retry logic for HUD startup to handle race conditions#965
Merged
LexiconCode merged 1 commit intoMay 16, 2026
Merged
Conversation
LexiconCode
approved these changes
May 16, 2026
Member
LexiconCode
left a comment
There was a problem hiding this comment.
Thank you. I really appreciate these pull requests! Every bit helps.
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.
Fix HUD connection race condition on cold boot
Description
I've updated
HudPrintMessageHandlerto include a retry loop when establishing the initial connection to the HUD process. Instead of failing instantly on the first ping, the handler will now poll for a connection up to 10 times with a 0.5-second delay. The hope is that this gives the OS enough time to spin up the background process and bind the port before Caster gives up and flags the HUD as inactive.Related Issue
Fixes #920
Motivation and Context
After running into this issue and discussing it with an LLM, I suspect this might be a race condition occurring on a cold startup. It seems like when running Caster for the first time after a boot,
start_hudlaunches the HUD viasubprocess.Popen, but the main Caster thread continues executing and attempts to ping the HUD before the OS has fully opened the port.This appears to result in the
[WinError 10061] Connection Refusederror, leaving a blank white HUD window. Restarting Caster usually bypasses the error, likely due to OS caching making the process load much faster the second time around. This fix is an attempt to ensure Caster gracefully waits for the HUD to wake up before throwing the error.How Has This Been Tested
Tested by observing Caster's initial startup immediately following a full system reboot. It appears that the new polling loop successfully catches the delay, waits for the port to open, and connects to the HUD GUI, avoiding the instant
[WinError 10061]failure I was seeing previously.Types of changes
Checklist
Maintainer/Reviewer Checklist