a2aproject / a2aproject/a2a-tck
[Bug]: test_content_type_not_supported_error sends unparseable JSON and tests the HTTP header, not Part.media_type
- Dominant language
- Python
- Stars
- 50
- Forks
- 40
- Avg merge
- 7d 1h
- Merged PRs (30d)
- 1
Description
### What happened?
`TestJsonRpcErrorCodeMappings::test_content_type_not_supported_error` (`tests/compatibility/jsonrpc/test_error_codes.py:200-241`) sends a deliberately malformed body and appears to test the wrong thing.
Two separate issues in the same test:
**1. The payload isn't valid JSON.** The body is built with `str(payload).encode()` on a Python `dict`:
```python
payload = {
"jsonrpc": "2.0",
"id": 1,
"method": "SendMessage",
"params": {...},
}
response = httpx.post(
client.base_url,
content=str(payload).encode(),
headers={"Content-Type": "text/plain", A2A_VERSION_HEADER: A2A_VERSION},
)
```
`str(dict)` produces Python repr with single quotes (`{'jsonrpc': '2.0', ...}`), which is not valid JSON (`json.loads(str(payload))` raises `JSONDecodeError: Expecting property name enclosed in double quotes`). A server that correctly parses JSON has no way to return `ContentTypeNotSupportedError` specifically — the body itself is unparseable independent of the `Content-Type` header, so a generic `ParseError` (-32700) is the more defensible response, and the test's fallback path (`pytest.skip` when the response isn't JSON or has no `"error"` key) suggests this ambiguity was anticipated but not resolved — a server returning `ParseError` in the JSON-RPC error envelope (valid JSON, has `"error"`) falls through to the `validate_jsonrpc_error(body, "ContentTypeNotSupportedError")` assertion and fails, rather than being skipped or accepted.
**2. Wrong semantic target.** `ContentTypeNotSupportedError` (-32005) is spec'd as "*A Media Type provided in the request's message parts or implied for an artifact is not supported by the agent or the specific skill being invoked*" (`specification.md:561`, `specification.md:1188`) — i.e. it's about the `media_type` of a `Part` inside the message, not the HTTP transport-envelope `Content-Type` header. This test manipulates the latter.
### Reproduction
```python
import json
payload = {"jsonrpc": "2.0", "id": 1, "method": "SendMessage"}
json.loads(str(payload)) # -> json.decoder.JSONDecodeError
```
Running the test against a spec-conformant server that returns `ParseError` (-32700) for the unparseable body:
```bash
pytest tests/compatibility/jsonrpc/test_error_codes.py::TestJsonRpcErrorCodeMappings::test_content_type_not_supported_error -v --sut-host=http://localhost:9999
```
→ `AssertionError: JSONRPC-SSE-002 ... Error code mismatch: expected ContentTypeNotSupportedError (-32005), got ParseError (-32700)`.
### Expected
- Use `json.dumps(payload)` (valid JSON body) for the transport-envelope-only case, if the intent is genuinely to test wrong-`Content-Type`-with-otherwise-valid-JSON handling.
- If the intent is to test `ContentTypeNotSupportedError` per spec, the mutation should be in a message `Part`'s `media_type`/`mimeType` field (with a syntactically valid envelope), not the HTTP header.
Happy to send a PR for either interpretation if a maintainer can confirm which one was intended.
Contributor guide
Assessment
This issue has not been assessed yet.