test: use httpx content for raw MCP payload#266
Conversation
TateLyman
left a comment
There was a problem hiding this comment.
No blockers found in PR #266. I reviewed the MCP malformed-request regression because the behavior depends on sending an actually invalid JSON request body, not a form/data helper path.
Evidence checked:
- Inspected
tests/test_api_mcp.py; the changed test now usescontent="not-json"withcontent-type: application/json, so Starlette/FastAPI receives the raw malformed body the assertion is meant to cover. - Confirmed the expected response remains the existing JSON-RPC parse-error shape: HTTP
400, code-32700, messageParse error, idNone, so the change only hardens test setup rather than changing runtime behavior. - Ran
uv run --python 3.12 --extra dev pytest tests/test_api_mcp.py::test_mcp_rejects_malformed_requests_without_500 -q-> 1 passed. - Ran
uv run --python 3.12 --extra dev pytest tests/test_api_mcp.py -q-> 41 passed. - Ran
uv run --python 3.12 --extra dev ruff check tests/test_api_mcp.py-> passed. - Ran
uv run --python 3.12 --extra dev ruff format --check tests/test_api_mcp.py-> 1 file already formatted. - Ran
git diff --check origin/main...HEAD-> clean. - Hosted
Quality, readiness, docs, and image checksis green.
No secrets, wallet material, payout details, private deployment values, private vulnerability details, or MRWK price claims were reviewed or disclosed.
|
No blockers from my review. Evidence checked:
This is a test-only compatibility fix and I did not see behavior risk in app code. |
MolhamHamwi
left a comment
There was a problem hiding this comment.
No blockers from my review.
Evidence checked:
- Inspected the complete diff; it only changes
tests/test_api_mcp.py::test_mcp_rejects_malformed_requests_without_500fromdata="not-json"tocontent="not-json". - Verified this keeps the malformed request body as raw bytes/text while preserving the explicit
content-type: application/jsonheader, which is the behavior the MCP 400 regression test needs. - Ran
UV_CACHE_DIR=/tmp/uv-cache-mergework uv run --python 3.12 --extra dev python -m pytest tests/test_api_mcp.py::test_mcp_rejects_malformed_requests_without_500 -q-> 1 passed. - Ran
UV_CACHE_DIR=/tmp/uv-cache-mergework uv run --python 3.12 --extra dev python -m ruff check tests/test_api_mcp.py-> all checks passed. - Ran
UV_CACHE_DIR=/tmp/uv-cache-mergework uv run --python 3.12 --extra dev python -m ruff format --check tests/test_api_mcp.py-> already formatted.
No secrets, wallet private keys, payout details, private deployment values, private vulnerability details, or MRWK price claims were reviewed or disclosed.
weilixiong
left a comment
There was a problem hiding this comment.
LOW risk, MCP raw payload test. MW #219.
MolhamHamwi
left a comment
There was a problem hiding this comment.
No blockers from my review.
Evidence checked:
- Inspected the diff in
tests/test_api_mcp.py; the malformed JSON request now uses httpx/TestClientcontent="not-json"withcontent-type: application/json, so the test exercises Starlette/FastAPI's raw-body JSON parser instead of form/data encoding behavior. - Compared against
app/main.py/mcp:await request.json()catchesValueErrorand returns the expected JSON-RPC parse error with HTTP 400, while non-object payloads still hit the separate invalid-request branch. - Ran
./.venv312/bin/python -m pytest tests/test_api_mcp.py::test_mcp_rejects_malformed_requests_without_500 -q-> 1 passed. - Ran
./.venv312/bin/python -m ruff check tests/test_api_mcp.py-> passed. - Ran
./.venv312/bin/python -m ruff format --check tests/test_api_mcp.py-> 1 file already formatted. - Checked GitHub Actions:
Quality, readiness, docs, and image checksis passing.
No secrets, wallet material, payout credentials, private deployment values, private vulnerability details, or MRWK price claims were reviewed or disclosed.
Summary
Refs #228.
The malformed MCP request test sends raw JSON text using
data=..., which httpx now warns is deprecated for raw request bodies.This switches the test to
content=..., preserving the same request body and headers while avoiding the deprecation path.Validation
The remaining warning is the Alembic
path_separatorwarning addressed separately in #264.