From 0d868d32ee81ce8de26d9677c7d89e6f39885965 Mon Sep 17 00:00:00 2001 From: Daniel Han Date: Tue, 28 Jul 2026 05:42:46 -0700 Subject: [PATCH] Pin utf-8 on the two marker reads/writes added with the Vulkan backend (#7507) test_shipping_code_names_an_encoding is red on main. #7373 added sync_marker_llama_backend, whose read_text/write_text pair does not name an encoding, so both fall back to locale.getencoding(): AssertionError: 2 text read/write call sites in shipping code let the operator's locale decide the encoding, so they crash or silently produce mojibake on Windows. Pass encoding = "utf-8": ['studio/install_llama_prebuilt.py:5656: write_text()', 'studio/install_llama_prebuilt.py:5647: read_text()'] Reproduced on a clean checkout of main at 7917c7828: 1 failed, 7 passed. That guard landed in #7486 a few commits earlier, so the rule predates these call sites; nothing about the Vulkan work is wrong beyond the missing kwarg. The create path that writes the same file, 26 lines above at 5621, already passes encoding = "utf-8", so main is also internally inconsistent about one file: written as utf-8, read back under the operator locale. Scope, stated honestly: json.dumps defaults to ensure_ascii = True, so the marker this module writes is pure ASCII and round-trips under cp1252 as well as utf-8. The exposure is a marker produced or edited by something else. A decode failure on the read would not even surface, because UnicodeDecodeError subclasses ValueError and the surrounding except (OSError, ValueError) swallows it into the early return, leaving the backend silently unsynced. So this restores a green suite and makes the file self-consistent rather than fixing a live crash. Verified: tests/test_runtime_text_encoding.py 1 failed / 7 passed before, 8 passed after; tests/test_source_read_encoding.py still passes.