Resolution search

[ngoiyaeric]

The open ai model is not responding on the resolution search.

[ngoiyaeric]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Fix the direct cause first: replace the invalid gpt-5.6-terra id in getModel() with the valid, vision-capable gpt-4o, so the OpenAI call in resolution search succeeds.
• Harden getModel() so unrecognized selectedModel values (including the reused tool-picker values) resolve to a valid model instead of a broken default path.
• Add a timeout to the resolution-search model call so a non-responding provider produces a real error rather than a silent hang.
• Surface resolution-search failures through the summary stream, BotMessage, and a carousel toast so users see a clear result instead of a stuck spinner or a bare error.

Design Choices

Design Choice 1: Which real OpenAI model id should replace `gpt-5.6-terra` in the default branch?

Options Considered:

1. Use gpt-4o, matching the existing final fallback and the 'GPT-5.1' switch case. It is vision-capable, which suits the image-analysis use case.
2. Introduce a configurable environment variable (for example OPENAI_MODEL_ID) with a gpt-4o default.

Chosen Option: 1

Rationale: The current default branch uses an id that does not exist. Other branches in the same function already use gpt-4o. gpt-4o is already the proven, vision-capable id used elsewhere in getModel(). It restores a working, consistent default with the least risk.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Correct model resolution in getModel()

This phase fixes the direct cause of the non-response. The goal is to make every code path in getModel() return a valid, vision-capable model when needed, and to prevent non-model selection values from silently reaching a broken branch.

Task 1: Replace the invalid default OpenAI model id

Restore a working OpenAI model in the default provider chain.

• Update lib/utils/index.ts in getModel(). Change the default OpenAI branch that returns openai('gpt-5.6-terra') to return a valid id (gpt-4o).
• Confirm the try/catch around the OpenAI client construction remains, so a missing key still falls through to the next provider.
• Keep the final catch-all consistent with the same valid id.

Task 2: Honor `requireVision` in the default OpenAI branch

Ensure image analysis requests always target a vision-capable model.

• Update lib/utils/index.ts so the default OpenAI branch accounts for the requireVision argument. The chosen id (gpt-4o) is vision-capable, so document that resolution search (which always passes hasImage = true) now receives a valid vision model.
• Verify the xAI default branch already swaps to a vision model when requireVision is true, and keep that behavior unchanged.

Task 3: Prevent non-model selection values from bypassing the switch

Stop values such as "QCX-Terra", "SkyFi", or unknown labels from falling through to the default branch in an undefined way.

• Update lib/utils/index.ts getModel(). Add a default case to the selectedModel switch, or an explicit allow-list check, so unrecognized selectedModel values fall through cleanly to the provider chain that now returns a valid model.
• Document the structural note: users.selected_model is written by both the LLM picker and the Settings tool picker. This task does not restructure that column; it only makes getModel() resilient to values it does not recognize.
• Add a warning log when selectedModel is set but matches no known case, to aid future debugging.

🤖 Prompt for AI agents

Implement Phase 1: correct the model resolution logic in `getModel()` in
`lib/utils/index.ts` so it always returns a valid, vision-capable model and
never lets unrecognized selection values reach a broken path.

- In the default OpenAI branch of `getModel()`, replace the invalid model id
`gpt-5.6-terra` with the valid id `gpt-4o`. Keep the existing `try/catch` around
the OpenAI client construction, so a missing key still falls through to the next
provider in the chain (xAI → Gemini → Bedrock). Update the final catch-all
fallback to use the same valid id `gpt-4o` for consistency.

- Update the default OpenAI branch so it accounts for the `requireVision`
argument. Since `gpt-4o` is vision-capable, this ensures resolution search,
which always calls `getModel(hasImage)` with `hasImage = true`, receives a valid
vision model. Do not change the existing xAI default branch behavior, which
already swaps to a vision model when `requireVision` is true.

- Add a `default` case to the `selectedModel` `switch` statement in
`getModel()`, or an equivalent explicit allow-list check, so that unrecognized
`selectedModel` values (for example `"QCX-Terra"`, `"SkyFi"`, or `null`, which
come from the reused `users.selected_model` column shared with the Settings tool
picker) fall through cleanly to the provider chain instead of hitting an
undefined path. Do not restructure the `users.selected_model` column; only make
`getModel()` resilient to unrecognized values. Add a warning log when
`selectedModel` is set but does not match any known case, to help with future
debugging.

Phase 2: Make resolution-search failures visible and bounded

This phase ensures that any future provider failure or hang produces a clear signal instead of a silent, indefinite wait. The goal is to convert silent hangs into reported errors and to keep the UI state consistent with actual completion.

Task 1: Add a timeout to the resolution-search model call

Convert an indefinite hang into a definite, catchable error.

• Update lib/agents/resolution-search.tsx. Pass an AbortSignal (for example via AbortSignal.timeout) or an equivalent timeout mechanism to the streamObject call, so a non-responding model rejects instead of hanging forever.
• On timeout, allow the error to propagate to the caller in app/actions.tsx so the existing catch handles it.

Task 2: Surface resolution-search errors in the UI

Replace the silent or generic failure display with a clear, resolution-search-specific message.

• Update app/actions.tsx processResolutionSearch. On error, in addition to summaryStream.error(error), write a descriptive user-facing message to the summary stream (for example, that analysis could not complete), so the user sees a meaningful result and the stream terminates.
• Confirm isGenerating.done(false) and uiStream.done() always run in the finally block so the flow ends cleanly.
• Review components/message.tsx BotMessage, where an errored stream currently renders a bare <div>Error</div>. Provide a clearer error indication for this flow, without changing unrelated chat behavior.

Task 3: Tie the carousel loading state to actual completion

Keep the "ANALYZING..." state accurate.

• Review components/resolution-carousel.tsx handleQCXAnalysis. The current code resets isAnalyzing as soon as actions.submit returns, because the server action is fire-and-forget. Tie the analyzing state and the toast.error to the actual completion or error of the streamed result, so the user receives a toast.error when analysis fails.

🤖 Prompt for AI agents

Implement Phase 2: make resolution-search failures visible and bounded, so a
non-responding model produces a reported error and the UI state reflects actual
completion, instead of hanging silently.

- In `lib/agents/resolution-search.tsx`, add a timeout mechanism to the
`streamObject` call. Pass an `AbortSignal` (for example via
`AbortSignal.timeout`) or an equivalent mechanism, so a non-responding model
rejects with an error instead of hanging indefinitely. On timeout, let the error
propagate to the caller in `app/actions.tsx`, where the existing `catch` block
handles it.

- In `app/actions.tsx`, update `processResolutionSearch` so that, on error, it
writes a descriptive user-facing message to the summary stream in addition to
calling `summaryStream.error(error)`. The message must tell the user that
analysis could not complete, so the stream terminates with a meaningful result
instead of a silent failure. Confirm that `isGenerating.done(false)` and
`uiStream.done()` always execute in the `finally` block, so the flow always ends
cleanly.

- Review `BotMessage` in `components/message.tsx`, where an errored stream
currently renders a bare `<div>Error</div>`. Provide a clearer error indication
for the resolution-search flow, without changing unrelated chat behavior.

- Review `handleQCXAnalysis` in `components/resolution-carousel.tsx`. Currently,
`isAnalyzing` resets as soon as `actions.submit` returns, because the server
action is fire-and-forget. Change this so the analyzing state and the
`toast.error` call are tied to the actual completion or error of the streamed
result, so the user sees a `toast.error` when analysis fails.

Research

The application uses the Vercel ai SDK with multiple provider clients (@ai-sdk/openai, @ai-sdk/xai, @ai-sdk/google, @ai-sdk/amazon-bedrock). All agents resolve their model through a single shared function, getModel(requireVision), in lib/utils/index.ts. This function reads a per-user value with getSelectedModel() from lib/actions/users.ts (DB column users.selected_model), runs a switch on known model labels, then falls through to a default provider chain (OpenAI → xAI → Gemini → Bedrock).

The resolution-search agent (lib/agents/resolution-search.tsx) calls streamObject({ model: await getModel(hasImage), ... }) with hasImage always true (it is an image-analysis agent). It runs through a standalone server-action path in app/actions.tsx (processResolutionSearch), triggered by the "QCX-TERRA ANALYSIS" button in components/resolution-carousel.tsx. This path is separate from the taskManager/researcher chat loop.

The root cause is in the default OpenAI branch of getModel(), which returns openai('gpt-5.6-terra'). This model id does not exist. The provider client constructs lazily and does not validate the id, so the error only surfaces later inside streamObject, outside any try/catch, with no fallback. The default branch also ignores requireVision. Additionally, the users.selected_model column is reused by a Settings tool picker, so non-model values ("QCX-Terra", "SkyFi", null) bypass the switch and hit the broken default branch.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: correct the model resolution logic in `getModel()` in
`lib/utils/index.ts` so it always returns a valid, vision-capable model and
never lets unrecognized selection values reach a broken path.

- In the default OpenAI branch of `getModel()`, replace the invalid model id
`gpt-5.6-terra` with the valid id `gpt-4o`. Keep the existing `try/catch` around
the OpenAI client construction, so a missing key still falls through to the next
provider in the chain (xAI → Gemini → Bedrock). Update the final catch-all
fallback to use the same valid id `gpt-4o` for consistency.

- Update the default OpenAI branch so it accounts for the `requireVision`
argument. Since `gpt-4o` is vision-capable, this ensures resolution search,
which always calls `getModel(hasImage)` with `hasImage = true`, receives a valid
vision model. Do not change the existing xAI default branch behavior, which
already swaps to a vision model when `requireVision` is true.

- Add a `default` case to the `selectedModel` `switch` statement in
`getModel()`, or an equivalent explicit allow-list check, so that unrecognized
`selectedModel` values (for example `"QCX-Terra"`, `"SkyFi"`, or `null`, which
come from the reused `users.selected_model` column shared with the Settings tool
picker) fall through cleanly to the provider chain instead of hitting an
undefined path. Do not restructure the `users.selected_model` column; only make
`getModel()` resilient to unrecognized values. Add a warning log when
`selectedModel` is set but does not match any known case, to help with future
debugging.
===============================================================================

Task: 2

Implement Phase 2: make resolution-search failures visible and bounded, so a
non-responding model produces a reported error and the UI state reflects actual
completion, instead of hanging silently.

- In `lib/agents/resolution-search.tsx`, add a timeout mechanism to the
`streamObject` call. Pass an `AbortSignal` (for example via
`AbortSignal.timeout`) or an equivalent mechanism, so a non-responding model
rejects with an error instead of hanging indefinitely. On timeout, let the error
propagate to the caller in `app/actions.tsx`, where the existing `catch` block
handles it.

- In `app/actions.tsx`, update `processResolutionSearch` so that, on error, it
writes a descriptive user-facing message to the summary stream in addition to
calling `summaryStream.error(error)`. The message must tell the user that
analysis could not complete, so the stream terminates with a meaningful result
instead of a silent failure. Confirm that `isGenerating.done(false)` and
`uiStream.done()` always execute in the `finally` block, so the flow always ends
cleanly.

- Review `BotMessage` in `components/message.tsx`, where an errored stream
currently renders a bare `<div>Error</div>`. Provide a clearer error indication
for the resolution-search flow, without changing unrelated chat behavior.

- Review `handleQCXAnalysis` in `components/resolution-carousel.tsx`. Currently,
`isAnalyzing` resets as soon as `actions.submit` returns, because the server
action is fire-and-forget. Change this so the analyzing state and the
`toast.error` call are tied to the actual completion or error of the streamed
result, so the user sees a `toast.error` when analysis fails.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---