Fix BUG: Windows build does not open on the first try.

[rahulharpal1603]

Fixes #872

Summary by CodeRabbit

• Improvements
  • Enhanced resilience of health checks during onboarding by increasing retry attempts for backend and microservice connectivity verification, reducing false timeouts due to temporary network issues.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

The retry policy for two backend health checks in the server validation component was increased from 10 to 60 attempts. This affects the main backend cluster health check and the sync microservice health check endpoints, allowing more time for servers to respond during initialization.

Changes

Cohort / File(s)	Summary
Health Check Retry Policy frontend/src/components/OnboardingSteps/ServerCheck.tsx	Increased retry count from 10 to 60 for both usePictoQuery calls: backend health check ('clusters') and sync microservice health check ('syncMicroservice'). No changes to logic, error handling, or control flow.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 Patience pays off, or so they say,
Sixty tries beats ten any day,
Windows now takes its sweet, sweet time,
To grant permissions and then align,
First try success—hop, hop, hooray! 🎉

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly relates to the main objective of fixing the Windows build startup issue mentioned in the PR objectives and linked issue.
Linked Issues check	✅ Passed	The code changes increase retry attempts for server health checks, which addresses the root cause of the Windows startup failure by improving initial server connection reliability.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to fixing the Windows build startup issue; only retry policy adjustments were made to the ServerCheck component.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4043751 and 1ff7d3d.

📒 Files selected for processing (1)

• frontend/src/components/OnboardingSteps/ServerCheck.tsx

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-10-31T17:00:50.132Z

Learnt from: Hemil36
Repo: AOSSIE-Org/PictoPy PR: 570
File: backend/app/database/connection.py:16-24
Timestamp: 2025-10-31T17:00:50.132Z
Learning: In PictoPy backend, the user prefers not to use database connection retry logic or extended busy timeouts in the centralized get_db_connection() context manager, even though the app has concurrent access patterns via ProcessPoolExecutor and FastAPI.

Applied to files:

• frontend/src/components/OnboardingSteps/ServerCheck.tsx

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: Tauri Build Check (ubuntu-22.04)
• GitHub Check: Tauri Build Check (windows-latest)
• GitHub Check: Tauri Build Check (macos-latest, --target aarch64-apple-darwin)
• GitHub Check: Backend Tests

🔇 Additional comments (1)

frontend/src/components/OnboardingSteps/ServerCheck.tsx (1)

25-26: Verify the context for this change and reconsider UX impact assumptions.

The retry value increases from an unknown prior value to 60 at lines 25-26 and 35-36, with a 1000ms delay between attempts. However, the commit message ("Increase retry attempts for server health checks to improve connection reliability") doesn't mention issue #872 or Windows firewall permissions. No reference to issue #872 or the described Windows permission scenario could be found in the codebase.

Before suggesting UX improvements based on the Windows firewall hypothesis, clarify:

• Does this change actually address Windows permission prompts, or is it a general reliability improvement?
• What was the previous retry value, and what timeouts was this replacing?
• Is the generic error message "Failed to connect to one or more local services" sufficient, or does the actual failure mode warrant more specific guidance?

If this is indeed addressing Windows-specific issues, then the suggested improvements (detecting permission states, updating loader messages, or configurable firewall rules) are reasonable. Otherwise, the 60-second timeout may be over-engineered for a different problem.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}