[python] Generated client sets `content-type` to `None` for empty body, causing `ValueError: No value for given attribute`

[xingwu1]

Body

Bug description

This appears to be a TypeSpec Python emitter bug, not a service-specific Batch bug.

In a TypeSpec-generated Azure Python SDK, BatchClient.begin_terminate_job() crashes when called with the default value for the optional options parameter, or with a default-constructed BatchJobTerminateOptions.

Actual behavior

Generated code leaves content_type = None when the request body is empty, but still unconditionally serializes the content-type header. This raises:

ValueError: No value for given attribute

[xingwu1]

Related Azure SDK for Python issue: Azure/azure-sdk-for-python#47201

[xingwu1]

Another Python SDK issue: Azure/azure-sdk-for-python#46815

[github-actions]

🎯 Issue Triage

The Python client emitter generates code that sets content_type = None for empty request bodies but still unconditionally serializes the content-type header, raising ValueError: No value for given attribute.

Category: Bug
Area: emitter:client:python

⚠️ No reproduction provided. A minimal repro would help diagnose this issue.

🔍 Analysis

• Affected component: http-client-python emitter
• Root cause: When the request body is optional/empty, the generated code does not guard the content-type header serialization against a None content type. The header serialization should be conditional on the content type being set.
• Related: Azure SDK for Python issue #47201 linked by the reporter shows the downstream impact.
• Affected method: BatchClient.begin_terminate_job() (and likely any generated method with an optional body where content_type can be None)

📝 Suggested next steps

• Reproduce with a minimal TypeSpec definition that generates a method with an optional/empty request body
• Identify where in the Python emitter the content-type header serialization is emitted without a None guard
• Fix the emitter to skip or conditionally set content-type when the body is empty/None

Generated by Agentic Triage

[msyyc]

Root cause analysis

Summary: For an operation with an optional body whose content-type is required/constant, calling it without a body leaves content_type = None, but the generated request builder serializes the content-type header unconditionally, so _SERIALIZER.header("content_type", None, "str") raises ValueError: No value for given attribute.

Generated code (azure-batch)

Operation _terminate_job_internal:

content_type: Optional[str] = kwargs.pop("content_type", _headers.pop("content-type", "application/json; odata=minimalmetadata"))
content_type = content_type if options else None      # -> None when optional body absent
...
_request = build_batch_terminate_job_internal_request(..., content_type=content_type, ...)

Request builder build_batch_terminate_job_internal_request:

content_type: str = kwargs.pop("content_type")                                       # required, no default
...
_headers["content-type"] = _SERIALIZER.header("content_type", content_type, "str")   # UNGUARDED -> crash on None

Where the bug lives in the emitter (http-client-python)

The generator handles the optional-body -> optional-content-type case only in the operation layer, not in the request-builder layer:

1. Operation layer is correct. _OperationSerializer.pop_kwargs_from_signature passes body_parameter=... into ParameterSerializer.pop_kwargs_from_signature (builder_serializer.py:656). There, is_content_type_optional = is_content_type and is_body_optional is True, so it types content_type as Optional[str] and emits content_type = content_type if options else None (parameter_serializer.py:200, 229).

2. Request-builder layer is missing that info. _RequestBuilderSerializer.pop_kwargs_from_signature (builder_serializer.py:459-465) does not pass body_parameter, so is_body_optional=False and content_type stays required (content_type: str = kwargs.pop("content_type")).

3. Header serialization isn't guarded. serialize_query_header (parameter_serializer.py:163-175) uses the unconditional branch if not param.optional and (param.in_method_signature or param.constant). The request-builder content-type param has optional=False (TCGC models content-type as required, since a body, when present, requires it), so the header is emitted with no if content_type is not None: guard.

The asymmetry is the defect: the operation knows the body is optional and passes content_type=None, while the request builder assumes content-type is always present.

Contrast: streaming-jsonl's build_basic_send_request works because TCGC models its content-type as optional, yielding the guarded if content_type is not None: form.

Fix direction

Mirror the operation's optional-body handling in the request builder: thread body_parameter into the request-builder pop_kwargs_from_signature, and make serialize_headers / serialize_query_header emit the content-type header under an if content_type is not None: guard (declaring it Optional[str] = kwargs.pop("content_type", None)) whenever the body is optional, so a None content-type is omitted instead of serialized.