Fix OpenAI empty choices panic

[ARYPROGRAMMER]

Summary

Fixed a panic error ("index out of bounds") that occurred when Goose interacted with OpenAI-compatible servers (like mlx_lm.server or LM Studio). The error was triggered when these servers sent response chunks with an empty choices array, as the code accessed elements like response["choices"][0] and chunk.choices[0] without checking if the array was empty first. The issue occurs rarely and is now almost guranteed to not occur.

---

Root Cause Analysis (RCA, perhaps)

The panic was caused by unsafe array access in the OpenAI response parsing logic:

• Streaming responses: The response_to_streaming_message() function directly accessed chunk.choices[0] without performing a bounds check.
• Non-streaming responses: The response_to_message() function directly accessed response["choices"][0]["message"] without validating the array's existence or length.

While an empty choices array is valid according to the OpenAI specification, the existing code did not handle this case, leading to a crash.

---

Technical Solution

Defensive bounds checking was implemented in both response parsing pathways to prevent the crash:

• Streaming Response Handler (response_to_streaming_message)

  • Added !chunk.choices.is_empty() guards before all accesses to choices[0].
  • Added !tool_chunk.choices.is_empty() checks within tool call processing loops.
  • Replaced direct access with safe pattern matching and bounds validation.

• Non-Streaming Response Handler (response_to_message)

  • Added explicit validation using response.get("choices").and_then(|c| c.as_array()).
  • Included checks for empty arrays with descriptive error messages.
  • Switched from direct indexing to safe array access methods.

---

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other

---

Testing

The fix was verified through the following steps:

• The project was built successfully using cargo build.
• Tests were conducted with an LM Studio server using both streaming and non-streaming requests.
• Confirmed that responses with empty choices arrays no longer cause panics.
• Verified that standard OpenAI API responses continue to work correctly.

Manual testing confirmed that Goose now gracefully handles empty choices arrays, ensuring compatibility with a wider range of OpenAI-compatible servers.

I can't actually test mlx server based but reverified with everything else. (needs apple chip)

---

Related Issues

Fixes #4276

---

[DOsinga]

thanks for fixing this. if you want I saw that databricks has a similar way of doing things.

[DOsinga]

this is probably good enough, but it feels more in line with the existing code to do something like:

let Some(original) = response
    .get("choices")
    .and_then(|c| c.get(0))
    .and_then(|m| m.get("message"))
else {
    return Ok(Message::with_content(Vec::new()));
};

i.e. if there is no content, we just return an empty message, same as if it is empty for other reasons below

[ARYPROGRAMMER]

Thanks for the review and the great suggestion, i've implemented your recommended change to use the more standard pattern that returns an empty message instead of an error when choices are missing or empty. This is indeed more consistent with how the rest of the codebase handles empty content cases.

lgtm now @DOsinga

[ARYPROGRAMMER]

this is completed i think

[DOsinga]

here we aleady guard for empty though, don't we? on line 473?

[ARYPROGRAMMER]

yeah just for safety, should not impact

[ARYPROGRAMMER]

just checking the build failure

[ARYPROGRAMMER]

@DOsinga please rerun ci pipelines for this, it should works now mostly

edit:

1. removed redundant null check
2. fixed message::new constructor

[DOsinga]

there is still some of that checking going on I think

[ARYPROGRAMMER]

there is still some of that checking going on I think

I think all have completed successfully now.

Thanks, glad I was able to fix this

[ARYPROGRAMMER]

@taniandjerry can you please add Hacktoberfest and Large label to this.

Thanks, I'll see this week's issues in a while