Static read-through audit of crates/dpp-common. Two verified findings.
1. Request-ID injection never fires for this platform's actual error format
Location: src/request_id.rs:51
Issue: v.contains("application/json") never matches application/problem+json — the exact media type this same crate's http_problem.rs:78 sets on every Problem response. "application/problem+json" does not contain "application/json" as a substring (the char after application/ is p, not j).
Failure scenario: inject_request_id falls through and never injects requestId into the one error format the platform actually emits, directly defeating the middleware's stated purpose ("enabling support conversations to start with a stable identifier") for its primary use case.
2. Oversized non-2xx JSON body silently replaced with an empty body
Location: src/request_id.rs:61
Issue: When a non-2xx response body exceeds the 64 KiB limit passed to axum::body::to_bytes, the Err branch discards the body entirely and substitutes Body::empty(), with no logging.
Failure scenario: A batch-import/validation error response whose payload legitimately exceeds 64 KB (this platform does batch DPP imports) returns correct headers/status but a completely empty body where JSON was expected, with nothing in logs indicating truncation.
Static read-through audit of
crates/dpp-common. Two verified findings.1. Request-ID injection never fires for this platform's actual error format
Location:
src/request_id.rs:51Issue:
v.contains("application/json")never matchesapplication/problem+json— the exact media type this same crate'shttp_problem.rs:78sets on everyProblemresponse."application/problem+json"does not contain"application/json"as a substring (the char afterapplication/isp, notj).Failure scenario:
inject_request_idfalls through and never injectsrequestIdinto the one error format the platform actually emits, directly defeating the middleware's stated purpose ("enabling support conversations to start with a stable identifier") for its primary use case.2. Oversized non-2xx JSON body silently replaced with an empty body
Location:
src/request_id.rs:61Issue: When a non-2xx response body exceeds the 64 KiB limit passed to
axum::body::to_bytes, theErrbranch discards the body entirely and substitutesBody::empty(), with no logging.Failure scenario: A batch-import/validation error response whose payload legitimately exceeds 64 KB (this platform does batch DPP imports) returns correct headers/status but a completely empty body where JSON was expected, with nothing in logs indicating truncation.