Hmbown/CodeWhale · error

fixture catalog parses

Error message

fixture catalog parses

What it means

This `expect` panics when the fixture catalog JSON string fails to deserialize into the expected offerings type, aborting with 'fixture catalog parses' at crates/tui/src/client.rs:7897. The test feeds a hand-written catalog JSON to the parser and requires it to be schema-valid before recording a success delta.

Solutions

1. Print the serde error (`unwrap_or_else(|e| panic!("fixture catalog parses: {e}"))`) to see the exact field/path mismatch
2. Update the fixture string to match the current `ProviderCatalogDelta`/offerings schema
3. Check whether new required fields were added to the catalog model
4. Validate the fixture JSON with a quick `serde_json::from_str::<Value>` to separate syntax from schema errors

Example fix

// before
.parse(...)
.expect("fixture catalog parses");
// after
.parse(...)
.unwrap_or_else(|e| panic!("fixture catalog parses: {e}"));

let parsed: serde_json::Value = serde_json::from_str(FIXTURE)
    .expect("fixture is syntactically valid JSON");
assert!(parsed.get("offerings").is_some(), "fixture missing offerings");

let offerings = parse_catalog(FIXTURE)
    .unwrap_or_else(|e| panic!("fixture catalog parses: {e}"));

When it happens

Trigger: Calling the catalog parse function with a fixture string whose JSON shape no longer matches the catalog struct — a renamed field like `usable`/`default`, a missing `offerings` array, or wrong enum casing for the provider name.

Common situations: The catalog schema evolved (new required field, stricter serde deny_unknown_fields) after the fixture was written; a typo in the embedded JSON literal; serde attributes changed from default to required.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• continue_goal with a wire-supplied schedule id still parses
• deserialize
• effective permissions should round-trip
• legacy route should parse
• roundtrip

AI-assisted analysis of Hmbown/CodeWhale@73e0f67d83 (2026-09-22). Data as JSON: /api/errors/fe5bf966d69ef76e. Report an issue: GitHub.

Appendix: source

Thrown at crates/tui/src/client.rs:7897

            .expect(1)
            .mount(&server)
            .await;

        // Seed the account catalog through the same refresh seam the runtime
        // uses, so the wire choice comes from the row's stated protocol.
        let fingerprint = base_url_fingerprint(&server.uri());
        let offerings = codewhale_catalog_offerings_from_body(
            r#"{"object":"list","data":[
                {"id":"openai/gpt-5.6","object":"model","owned_by":"openai",
                 "codewhale":{"provider":"openai","model":"gpt-5.6",
                              "protocol":"responses","endpoint":"/v1/responses",
                              "default":true,"usable":true}}
            ]}"#,
            "codewhale",
            &fingerprint,
            now_unix(),
        )
        .expect("fixture catalog parses");
        crate::provider_catalog_live::record_success(ProviderCatalogDelta {
            provider: "codewhale".to_string(),
            base_url_fingerprint: fingerprint,
            fetched_at: now_unix(),
            offerings,
        });

        let mut client = codewhale_client(&server, "openai/gpt-5.6");
        assert_eq!(client.wire_format, WireFormat::Responses);
        client.retry.enabled = false;
        let response = client
            .create_message(minimal_zen_request("openai/gpt-5.6"))
            .await
            .expect("Codewhale responses request should succeed");

        // Responses usage arrives on the terminal `response.completed` event —
        // the dialect's equivalent of chat's `stream_options.include_usage`.
        assert_eq!(response.usage.input_tokens, 3);

View on GitHub (pinned to 73e0f67d83)