juspay/hyperswitch · warning

failed to build the test response

Error message

failed to build the test response

What it means

A test helper builds an in-memory `reqwest::Response` via `http::Response::Builder` and calls `.expect("failed to build the test response")`. If the builder is misused (e.g. an invalid header name/value passed to `.header()`), building the body panics inside the test `repeated_headers_survive_capture_and_reconstruct`.

Solutions

  1. Fix the offending header name/value in the test fixture to be valid HTTP header tokens
  2. Use `HeaderValue::from_bytes(...)` in a checked loop and skip/report invalid entries instead of passing raw strings

Example fix

// before
builder = builder.header(name, value);
// after
let val = http::HeaderValue::from_str(value).expect("test header value must be valid");
builder = builder.header(name, val);
Defensive patterns

Strategy: validation

Validate before calling

if let Err(e) = http::HeaderValue::from_str(value) { panic!("invalid test header {name}: {e}"); }

Type guard

fn is_valid_header(name: &str, value: &str) -> bool {
    http::HeaderName::try_from(name).is_ok() && http::HeaderValue::try_from(value).is_ok()
}

Try / catch

builder.body(body).unwrap_or_else(|e| panic!("failed to build the test response: {e}"))

Prevention

When it happens

Trigger: The header name/value pairs in the test's list are invalid (illegal characters, non-visible-ASCII values), causing `ResponseBuilder::body()` to return Err and the expect to panic.

Common situations: Editing the repeated-headers test fixture with a header value containing invalid bytes or a malformed header name.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors


AI-assisted analysis of juspay/hyperswitch@afd9284352 (2026-09-18). Data as JSON: /api/errors/c15a5ffbe0abc20c. Report an issue: GitHub.

Appendix: source

Thrown at crates/external_services/src/http_client/boundary.rs:266

    /// Three `set-cookie` headers must survive capture and reconstruct as three.
    ///
    /// Fails on the `insert`-per-name capture this replaced, which kept one value
    /// per name and so recorded a single cookie.
    #[test]
    fn repeated_headers_survive_capture_and_reconstruct() {
        let mut builder = http::Response::builder().status(200);
        for (name, value) in [
            ("x-request-id", "req-1"),
            ("set-cookie", "a=1"),
            ("set-cookie", "b=2"),
            ("set-cookie", "c=3"),
        ] {
            builder = builder.header(name, value);
        }
        let source = reqwest::Response::from(
            builder
                .body(bytes::Bytes::from_static(b"{}"))
                .expect("failed to build the test response"),
        );

        let result: CustomResult<reqwest::Response, HttpClientError> = Ok(source);
        let (captured, _) = response_result(&result);
        let captured = captured.expose();

        let reconstructed =
            replay_response(&captured).expect("a captured response must reconstruct");
        let cookies: Vec<&str> = reconstructed
            .headers()
            .get_all("set-cookie")
            .iter()
            .filter_map(|value| value.to_str().ok())
            .collect();
        assert_eq!(
            cookies,
            ["a=1", "b=2", "c=3"],
            "every set-cookie value must survive the round trip"

View on GitHub (pinned to afd9284352)