Issue Station
Sign In
Tools hereToolbox

litellm - ✅(Solved) Fix [Bug] Zhipu GLM returns non-standard finish_reason ("network_error", "sensitive") causing Pydantic crash [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#23386•Fetched 2026-04-08 00:37:03
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
K-TemplarK-Templar
Participants
johnowhitakerjohnowhitakerK-TemplarK-Templar
Timeline (top)
closed ×1commented ×1cross-referenced ×1labeled ×1

When using Zhipu GLM models through LiteLLM, streaming requests that fail mid-inference return non-standard finish_reason values that crash LiteLLM's Pydantic validation instead of being handled gracefully.

Error Message

pydantic_core._pydantic_core.ValidationError: 1 validation error for Choices finish_reason Input should be 'stop', 'content_filter', 'function_call', 'tool_calls', 'length', 'guardrail_intervened', 'eos', 'finish_reason_unspecified' or 'malformed_function_call' [type=literal_error, input_value='network_error', input_type=str]

This bubbles up as:

litellm.APIError: Error building chunks for logging/streaming usage calculation

Root Cause

When using Zhipu GLM models through LiteLLM, streaming requests that fail mid-inference return non-standard finish_reason values that crash LiteLLM's Pydantic validation instead of being handled gracefully.

Fix Action

Fixed

PR fix notes

PR #24373: fix: map Zhipu GLM non-standard finish_reason values

Description (problem / solution / changelog)

Relevant issues

Fixes https://github.com/berriAI/litellm/issues/23386

Pre-Submission checklist

  • I have Added testing in the tests/test_litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Type

🐛 Bug Fix

Changes

Zhipu GLM returns non-standard finish_reason values during streaming when inference fails mid-request. These values are not in LiteLLM's _FINISH_REASON_MAP, causing a Pydantic validation crash in stream_chunk_builder.

Add two mappings to the centralized _FINISH_REASON_MAP in core_helpers.py:

  • "network_error" → "stop" (inference interrupted)
  • "sensitive" → "content_filter" (content policy violation)

Tests added

  • TestMapFinishReasonZhipu::test_network_error
  • TestMapFinishReasonZhipu::test_sensitive

Changed files

  • litellm/litellm_core_utils/core_helpers.py (modified, +3/-0)
  • tests/test_litellm/litellm_core_utils/test_core_helpers.py (modified, +8/-0)
RAW_BUFFERClick to expand / collapse

[Bug] Zhipu GLM returns non-standard finish_reason values ("network_error", "sensitive") causing Pydantic validation crash

Description

When using Zhipu GLM models through LiteLLM, streaming requests that fail mid-inference return non-standard finish_reason values that crash LiteLLM's Pydantic validation instead of being handled gracefully.

Error

pydantic_core._pydantic_core.ValidationError: 1 validation error for Choices finish_reason Input should be 'stop', 'content_filter', 'function_call', 'tool_calls', 'length', 'guardrail_intervened', 'eos', 'finish_reason_unspecified' or 'malformed_function_call' [type=literal_error, input_value='network_error', input_type=str]

This bubbles up as:

litellm.APIError: Error building chunks for logging/streaming usage calculation

Raw API Response from Zhipu

json { "id": "202603031103252ba2e084c0074fc3", "created": 1772507037, "model": "GLM-5", "choices": [ { "index": 0, "finish_reason": "network_error", "delta": {"role": "assistant", "content": ""} } ] } Zhipu's Documented Behavior

From Zhipu's API docs (translated):

"When using streaming (SSE) calls, if the API terminates abnormally during inference, it will not return error codes, but will return the abnormal reason in the finish_reason parameter of the response body."

Known non-standard finish_reason values from Zhipu:

• network_error — inference interrupted due to network issues • sensitive — content policy violation / sensitive content detected

Expected Behavior

LiteLLM should map Zhipu's non-standard finish_reason values to OpenAI-compatible equivalents:

Zhipu ValueMap ToRationale
network_errorstopInference interrupted, model is done
sensitivecontent_filterContent policy violation
Additionally, the original value should be preserved in provider_specific_fields.finish_reason for debugging.

Actual Behavior Pydantic validation fails, the entire response is lost, and the stream crashes with an unhandled litellm.APIError.

Steps to Reproduce

  1. Configure LiteLLM with a Zhipu GLM model (e.g., GLM-5)
  2. Make a streaming request
  3. If Zhipu's infrastructure hiccups mid-inference, it returns finish_reason: "network_error"
  4. LiteLLM's stream_chunk_builder fails Pydantic validation
  5. Stream crashes

Environment

• LiteLLM: latest (main-stable) • Provider: Zhipu GLM-5 • Streaming: Yes (SSE)

Related Issues

• #21348 — Proposal to ensure finish_reason values are OpenAI-compatible across providers • #23273 — Same issue with Gemini returning finish_reason: "error" • Spring AI #5530 — Same Zhipu issue in Spring AI framework

Proposed Fix

Add mappings to map_finish_reason() in litellm/litellm_core_utils/core_helpers.py:

Zhipu GLM mappings "network_error": "stop", "sensitive": "content_filter", This aligns with the mapping criteria in #21348:

• network_error → stop (model is done, no valid continuation) • sensitive → content_filter (content was blocked)

Impact

This affects any user of LiteLLM proxy with Zhipu GLM models. The unhandled crash prevents retry logic and causes frustrating stream failures that appear to be LiteLLM bugs but are actually provider quirks that LiteLLM should normalize.

extent analysis

Fix Plan

To resolve the issue, we need to update the map_finish_reason() function in litellm/litellm_core_utils/core_helpers.py to include mappings for Zhipu's non-standard finish_reason values.

Steps:

  1. Update map_finish_reason() function:

def map_finish_reason(finish_reason, provider): # Existing mappings... if provider == "Zhipu": finish_reason_mapping = { "network_error": "stop", "sensitive": "content_filter" } return finish_reason_mapping.get(finish_reason, finish_reason) # Existing mappings for other providers... ``` 2. Preserve original value in provider_specific_fields:

def process_response(response):
 # ...
 provider_specific_fields = {}
 if 'finish_reason' in response and response['finish_reason'] not in ['stop', 'content_filter', 'function_call', 'tool_calls', 'length', 'guardrail_intervened', 'eos', 'finish_reason_unspecified', 'malformed_function_call']:
     provider_specific_fields['finish_reason'] = response['finish_reason']
 # ...
 ```
3. **Handle Pydantic validation**:
Update the Pydantic model to allow for the new `finish_reason` values or use a custom validation function to handle the non-standard values.

### Verification
To verify the fix, test the streaming request with Zhipu GLM models and simulate network errors or sensitive content detection. The response should now be handled correctly, and the stream should not crash.

### Extra Tips
* Monitor the `provider_specific_fields` for any new non-standard `finish_reason` values from Zhipu or other providers.
* Consider adding a fallback mechanism to handle unknown `finish_reason` values from providers.
* Review the related issues (#21348, #23273, Spring AI #5530) to ensure consistency across providers and frameworks.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#network issue#index setup#retrieval issue#search optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING