fix: guard against IndexError on empty LLM choices/content list

[qizwiz]

Problem

Three files access choices[0] or content[0] without first checking whether the API returned any results. An empty list can occur when:

• the LLM applies a content-policy filter and returns choices=[]
• a token limit is hit before the first choice arrives
• a rate-limit fallback returns a non-standard response body
• the Anthropic API returns content=[] on a refusal

This raises a bare IndexError that propagates as an unhandled exception.

Changes

File	Line	Fix
fastchat/serve/api_provider.py	351	if not res.choices: return before accessing choices[0]
fastchat/serve/monitor/classify/label.py	67	if not completion.choices: break before accessing choices[0]
fastchat/serve/monitor/classify/label.py	117	if not response.content: break before accessing Anthropic content[0]
fastchat/serve/monitor/criteria_labeling.py	92	if not completion.choices: break before accessing choices[0]

All three files already use retry loops — break on empty response exits the loop and returns the API_ERROR_OUTPUT sentinel, which is the same behaviour as any other API error.

No new files, no behaviour change on successful API responses.

---

Found by pact static analysis — llm_response_unguarded mode.

[qizwiz]

Update: extended guards to cover a second crash vector

Testing against live providers revealed that Gemini 2.5 Flash returns HTTP 200 with choices[0].message = None (not an empty choices list) when content is filtered — finish_reason: PROHIBITED_CONTENT. The previous guards if not completion.choices: and if not res.choices: only prevent IndexError; they do not prevent AttributeError: 'NoneType' object has no attribute 'content' when message itself is None.

Pushed a follow-up commit (cab948d) extending all three guards:

• fastchat/serve/monitor/classify/label.py
• fastchat/serve/monitor/criteria_labeling.py
• fastchat/serve/api_provider.py

New guard pattern: if not completion.choices or completion.choices[0].message is None: