Skip to content

Fix hardcoded Model status to reflect runtime state#46

Open
wpflueger wants to merge 1 commit intomainfrom
fix/dynamic-model-status
Open

Fix hardcoded Model status to reflect runtime state#46
wpflueger wants to merge 1 commit intomainfrom
fix/dynamic-model-status

Conversation

@wpflueger
Copy link
Owner

Summary

  • The Model status card in the UI always showed "Ready"/"Loaded" regardless of actual backend state (e.g., after a crash or CUDA error)
  • Now derives the Model card display from the health check status.ready field, showing "Not Ready"/"Unavailable" when the model is down
  • Minimal change — uses existing health status data that was already being tracked

Test plan

  • Verify the Model card shows "Ready"/"Loaded" when backend is healthy
  • Kill the backend process and verify the card updates to "Not Ready"/"Unavailable"
  • Restart the backend and confirm it returns to "Ready"/"Loaded"

Closes #33

🤖 Generated with Claude Code

The Model status card always showed "Ready"/"Loaded" regardless of
actual backend state. Now derives the display from the health check
response, showing "Not Ready"/"Unavailable" when the model is down.

Closes #33

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings February 9, 2026 03:31
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the desktop UI’s “Model” status card to derive its displayed state from the tracked backend health status (status.ready) instead of hardcoded “Ready/Loaded”, aiming to reflect runtime backend/model availability.

Changes:

  • Replace hardcoded “Model: Ready / Loaded” with conditional rendering based on status.ready.
  • Show “Not Ready / Unavailable” styling when status.ready is false.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +226 to +227
<p className="value">{status.ready ? "Ready" : "Not Ready"}</p>
<span className={status.ready ? "pill" : "pill muted"}>{status.ready ? "Loaded" : "Unavailable"}</span>
Copy link

Copilot AI Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new "Not Ready/Unavailable" branch here is effectively unreachable because this component returns the startup view whenever !status.ready (see earlier if (!status.ready) return ...). As a result, the Model status card will never display the non-ready state in the main UI, which doesn't match the PR's stated behavior. Consider decoupling "backend connected" vs "startup/initializing" vs "model ready" state (e.g., track hasEverBeenReady / connectionState, or keep rendering the main view with disabled controls and show the cards in a muted state when status.ready flips false).

Copilot uses AI. Check for mistakes.
Comment on lines +226 to +227
<p className="value">{status.ready ? "Ready" : "Not Ready"}</p>
<span className={status.ready ? "pill" : "pill muted"}>{status.ready ? "Loaded" : "Unavailable"}</span>
Copy link

Copilot AI Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change introduces new conditional UI states for the Model card, but there are no tests covering the main view or verifying that the Model card updates when backend status changes. Since App.test.tsx exists, consider adding a test that simulates a onBackendStatus callback toggling ready and asserts the Model label/pill text and class change accordingly.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Hardcoded 'Model: Ready' status doesn't reflect runtime state

2 participants