fix: remove content-type from headers in _add_from_file to avoid RuntimeError

[juliosuas]

Summary

Fixes #741.

The recorder stores content_type as a top-level YAML key and may also capture a content-type entry inside the headers dict (since HTTP servers return Content-Type as a response header). When _add_from_file() calls add() with both content_type= and headers={'content-type': ...}, it raises:

RuntimeError: You cannot define both `content_type` and `headers[Content-Type]`.
Using the `content_type` kwarg is recommended.

Fix

Strip any content-type key from headers before calling add() when content_type is also present in the loaded YAML. The content_type kwarg takes precedence (already recommended by the library).

if headers is not None and "content_type" in rsp:
    headers = {k: v for k, v in headers.items() if k.lower() != "content-type"}

This lets recorded YAML files be used in tests without any manual editing.

[juliosuas]

One thing to note: this only affects files loaded via _add_from_file() — not programmatic responses.add() calls which already raise the RuntimeError by design (the error message says content_type kwarg is recommended). The fix just makes recorded YAML files usable out-of-the-box without manual editing.

[markstory]

It would be good to have a test covering this scenario. I could help with the test if you can provide an example payload that is currently not working that will work after this change.

[juliosuas]

Added a regression test in tests/test_recorder.py — test_add_from_file_content_type_in_headers.

It creates a YAML fixture with Content-Type in the headers dict (which is exactly what the recorder produces) and verifies two cases:

1. When Content-Type is the only header — after stripping it, headers correctly becomes None
2. When there are other headers alongside Content-Type — the other headers survive, only Content-Type is removed

The test fails with RuntimeError before the fix and passes after, confirming it catches the exact regression. Let me know if you'd like additional coverage.

[markstory]

Suggested change

	"Content-Type": "text/plain",
	"Content-Type": "text/html",

Having a different value for headers and content_type will better capture the coalescing behavior mentioned in the comment.

[juliosuas]

Good catch @markstory — updated the test to use text/html in headers['Content-Type'] and application/json/text/plain in content_type. Now the assertion is non-trivial: it confirms content_type wins over the conflicting header value rather than passing trivially when both carry the same string.

[markstory]

You'll either need to save your file as toml, or switch the loader to yaml for this test.

[juliosuas]

Good catch @markstory — added .yaml extension to the fixture file so _add_from_file correctly selects the YAML loader by extension. The fix is minimal: yaml_file = Path(str(self.out_file) + ".yaml") and passing that path to _add_from_file.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[juliosuas]

Fixed both issues flagged by Cursor Bugbot:

1. Stale fixture file — teardown_method now cleans up .yaml and .toml extension variants in addition to the base response_record path.

2. Precedence assertion — the current test already uses mismatched values (headers["Content-Type"]: "text/html" vs content_type: "application/json" for GET, and "text/html" vs "text/plain" for POST), so the assertion is non-trivial. The bot's comment referenced an earlier version of the test before text/html was added per @markstory's suggestion.

[juliosuas]

Both issues flagged by Cursor Bugbot have been addressed (teardown cleanup for yaml/toml variants, and the non-trivial precedence assertion with mismatched values). The PR has @markstory's approval and all CI checks should be passing. Ready to merge when you have a moment — thanks!

[juliosuas]

Hi @markstory — just wanted to check in on this one. The fix is minimal (strips duplicate content-type from headers before calling add()), all three checks pass (Cursor Bugbot ✅, Seer Code Review ✅, Semgrep ✅), and you've already approved it. Is there anything else needed before merge?

[markstory]

Is there anything else needed before merge?

CI is failing.

[juliosuas]

Pushed a fix for the red CI. Root cause turned out to be test state leakage, not the Content-Type logic itself:

test_add_from_file[tomli_w] monkey-patches responses.mock._parse_response_file to a TOML loader and never restores it. When test_add_from_file_content_type_in_headers ran after it, the TOML parser was still installed on the singleton, so the YAML fixture blew up with tomllib.TOMLDecodeError: Expected '=' after a key in a key/value pair. The earlier attempts (renaming the fixture to .yaml, adding extension cleanup in teardown) didn't help because _parse_response_file always goes through yaml.safe_load regardless of extension — the dispatch is on the callable, not the filename.

Fix in teardown_method: always rebind responses.mock._parse_response_file to the class default, so any per-test monkey-patch is contained to that test.

Also picked up a black complaint in __init__.py — the Content-Type-stripping dict comp landed at 91 chars, reflowed it to stay under 88.

Happy to split this into two commits if you'd prefer the test-isolation fix and the formatting nit separately.

[markstory]

Wouldn't it be better to unwind the mock in the test that is doing the monkey patching?

[juliosuas]

Good call — refactored in ac93d8f to capture the original _parse_response_file and restore it in a finally block within test_add_from_file, instead of the class-wide reset in teardown_method. Removes the leaked responsibility from the teardown.