a2aproject / a2aproject/a2a-tck

[Bug]: test_content_type_not_supported_error sends unparseable JSON and tests the HTTP header, not Part.media_type

Open
#216 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.