EDM-2403: Handle initialization errors gracefully instead of panic

[celdrake]

Substitute all cases in which the UI was panicking by gracefully logging the error and exiting the main process.

Logs example when FLIGHTCTL_SERVER is an invalid URL:

Before:

Oct 23 XX:XX:XX flightctl-ui[XXXXX]: panic: parse "ht!tp://invalid url with spaces": first path segment in URL cannot contain colon
Oct 23 XX:XX:XX flightctl-ui[XXXXX]:
Oct 23 XX:XX:XX flightctl-ui[XXXXX]: goroutine 1 [running]:
Oct 23 XX:XX:XX flightctl-ui[XXXXX]: github.com/flightctl/flightctl-ui/bridge.createReverseProxy(...)
Oct 23 XX:XX:XX flightctl-ui[XXXXX]:         /app/bridge/handler.go:31
Oct 23 XX:XX:XX flightctl-ui[XXXXX]: github.com/flightctl/flightctl-ui/bridge.NewFlightCtlHandler(...)
Oct 23 XX:XX:XX systemd[1]: flightctl-ui.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

After:

Oct 23 04:58:14 flightctl-ui[27486]: time="2025-10-23T08:58:14Z" level=warning msg="Using InsecureSkipVerify for API communication"
Oct 23 04:58:14 flightctl-ui[27486]: time="2025-10-23T08:58:14Z" level=error msg="Failed to parse URL 'ht!tp://invalid url with spaces'" func=github.com/flightctl/flightctl-ui/bridge.createReverseProxy file="/app/bridge/handler.go:33" error="parse \"ht!tp://invalid url with spaces\": first path segment in URL cannot contain colon"
Oct 23 04:58:14 podman[27496]: container died ac4f87344bbc64c549d1d951eec08adc735f957e14460a002b621602c58f217a
Oct 23 04:58:14 systemd[1]: flightctl-ui.service: Main process exited, code=exited, status=1/FAILURE
Oct 23 04:58:14 systemd[1]: flightctl-ui.service: Failed with result 'exit-code'.

Summary by CodeRabbit

• Refactor
  • Enhanced error handling during startup with structured logging, replacing unexpected process crashes with graceful termination for improved diagnostics.

[coderabbitai]

Walkthrough

Panicking behavior replaced with structured error logging and graceful process termination across proxy initialization and request handling. Three error paths in proxy/app.go (TLS configuration, authentication initialization, TLS certificate loading) and one in proxy/bridge/handler.go (URL parsing) now log errors and exit with status 1 instead of panicking.

Changes

Cohort / File(s)	Summary
Error handling refactoring proxy/app.go, proxy/bridge/handler.go	Replaced panic(err) calls with structured logging followed by os.Exit(1) in four error handling paths: TLS configuration acquisition, authentication initialization, TLS certificate loading, and URL parsing. Maintains existing control flow and functional behavior while providing error visibility before process termination.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Straightforward, repetitive refactoring pattern applied consistently across two files
• Simple substitution of panic with log + exit; no complex logic changes
• All changes follow the same single pattern with minimal variance

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "EDM-2403: Handle initialization errors gracefully instead of panic" directly and accurately summarizes the main change in the changeset. Both modified files (proxy/app.go and proxy/bridge/handler.go) implement the same core pattern: replacing hard panics during initialization with structured error logging followed by controlled process exit using os.Exit(1). The title is specific and clear about what is being changed (panic behavior) and how it's being addressed (graceful error handling), avoiding vague terminology while remaining concise.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f7b0dc7 and 758bdae.

📒 Files selected for processing (2)

• proxy/app.go (3 hunks)
• proxy/bridge/handler.go (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

proxy/bridge/handler.go (1)

proxy/log/log.go (1)

• GetLogger (17-19)

⏰ 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: integration-tests
• GitHub Check: Build ocp plugin
• GitHub Check: Lint
• GitHub Check: Build

🔇 Additional comments (5)

proxy/app.go (3)

39-43: LGTM! Graceful error handling for TLS configuration.

The change from panic to structured logging with os.Exit(1) is appropriate for this initialization error. The error is logged with context before the process exits, improving observability.

---

75-79: LGTM! Graceful error handling for authentication initialization.

Consistent with the TLS configuration error handling. The structured logging approach provides clear error context before exiting.

---

95-99: LGTM! Graceful error handling for TLS certificate loading.

The error handling pattern is consistently applied. Since this occurs during initialization in main() before any resources are allocated or the server starts, calling os.Exit(1) is appropriate and doesn't bypass any cleanup.

proxy/bridge/handler.go (2)

8-8: LGTM! Necessary imports for error handling.

The os import enables os.Exit(1) for graceful termination, and the log import enables structured error logging. Both are necessary for the improved error handling pattern.

Also applies to: 13-13

---

30-35: LGTM! Graceful error handling for URL parsing.

The error handling is consistent with the changes in proxy/app.go. Using log.GetLogger() is appropriate here since this function doesn't have access to the logger instance initialized in main(). Including the problematic URL in the error message is helpful for debugging configuration issues.

Since createReverseProxy is called during handler initialization in main(), any URL parsing failure will prevent the server from starting, which is the correct behavior for invalid configuration.

---

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.}