chore: vulture whitelist for verified false-positive ensure_ascii (#1136)

pyproject.toml

@@ -237,6 +237,20 @@ exclude_lines = [
 [tool.bandit]
 exclude_dirs = ["tests"]
 
+# Dead-code scan whitelist (vulture, #1136). vulture auto-reads this section,
+# so it applies both to `python -m vulture src/` and to scripts/code_health.py.
+# Every name here is a VERIFIED false-positive — do not delete the code it
+# refers to; each entry must say why it is intentionally "unused".
+[tool.vulture]
+ignore_names = [
+    # src/utils/json.py safe_json_dumps(ensure_ascii=...): intentional
+    # call-site-compatibility parameter after the orjson migration (#956) —
+    # orjson is always UTF-8, the flag is accepted so existing
+    # `safe_json_dumps(obj, ensure_ascii=True)` calls don't break, but has
+    # no effect. Removing it would break call sites. See issue #1136.
+    "ensure_ascii",
+]
+
 # Doc-coverage (interrogate, #1072). scripts/doc_coverage.py and the advisory
 # CI step read this. `fail_under` is a SOFT baseline — a ratchet floor that
 # surfaces regressions without forcing a docstring-everything sprint. Raise it

tests/test_utils_json.py

@@ -69,6 +69,17 @@ def test_kwargs_forwarded():
     assert result == '{"a":2,"b":1}'
 
 
+def test_ensure_ascii_accepted_for_call_site_compat():
+    # `ensure_ascii` is an intentional no-op kept for call-site compatibility
+    # after the orjson migration (#956): orjson is always UTF-8. Live call
+    # sites pass it (e.g. generation_runs repository), so the parameter must
+    # keep being accepted with either value. Vulture-whitelisted in
+    # pyproject.toml [tool.vulture] — do not remove (#1136).
+    payload = {"text": "привет"}
+    assert safe_json_dumps(payload, ensure_ascii=True) == safe_json_dumps(payload, ensure_ascii=False)
+    assert "привет" in safe_json_dumps(payload, ensure_ascii=True)
+
+
 def test_custom_default_does_not_receive_datetime():
     # With a custom default, datetime must be serialized natively by orjson, NOT
     # routed to the caller's default (which may not handle it) — review on #956.