[BUG]: UnicodeDecodeError: 'gbk' codec can't decode byte on Windows during 'apm install' #3056

Activity

1. CheneyDu (CheneyDu0129)

   added

   type/bugSomething does not work as documented.Something does not work as documented.

   on Sep 22, 2026
2. github-project-automation

   added this to APM Roadmapon Sep 22, 2026
3. github-actions

   added

   area/cliCLI command surface, flags, help text (cross-cutting).CLI command surface, flags, help text (cross-cutting).

   triage/recommendedAutomated advice completed; not human scope approval.Automated advice completed; not human scope approval.

   on Sep 22, 2026
4. github-actions commented on Sep 22, 2026

   

   github-actionsbot

   on Sep 22, 2026 – with GitHub Actions

   More actions

   Triage recommendation: accept (advisory only -- a responsible human maintainer must still approve scope, priority, and review contact per GOVERNANCE.md).

   Thanks for isolating this to the Simplified Chinese (cp936/gbk) locale on Windows. The root cause is well-identified: the subprocess stdout/stderr reader thread relies on the platform default encoding instead of forcing UTF-8, so any non-ASCII byte sequence APM itself writes (or a child process emits) that isn't valid gbk raises an uncaught UnicodeDecodeError and crashes the install.

   Proposed scope: Force UTF-8 (with an explicit error-handling strategy, e.g. errors="replace") for the subprocess output reader thread(s) used during apm install, rather than relying on the OS default codepage.

   Proposed done-when: A test simulates non-UTF-8-decodable bytes on the subprocess stdout/stderr stream and confirms apm install completes without raising UnicodeDecodeError; ideally a Windows/cp936-locale CI case or a decode-focused unit test is added.

   Exclusions: No broader change to encoding handling outside the subprocess reader path.

   Review needs: A maintainer familiar with the install subprocess/streaming-output code, ideally with Windows testing capability.

   Generated by Triage Panel · copilot · auto · 165.1 AIC · ⌖ 5.28 AIC · ⊞ 12K · ◷
5. danielmeppiel commented on Oct 1, 2026

   

   Daniel Meppiel (danielmeppiel)

   on Oct 1, 2026

   Collaborator

   More actions

   Decision: approve
   Area: project
   Scope: Fix the failing Windows subprocess decoding boundary during installation so non-English locales do not crash a valid install, while preserving machine-readable output semantics.
   Done when: A regression covers the reported Windows/locale failure; valid output is decoded deterministically, malformed machine output is surfaced rather than silently corrupted, and existing command failure behavior remains intact.
   Out of scope: Blanket silent replacement or dropping of malformed machine output, unrelated encoding rewrites, or masking subprocess failures.
   Review contact: Daniel Meppiel (@danielmeppiel)

   Installation should not depend on the developer's Windows locale.

   Recorded by Copilot on behalf of Daniel Meppiel (@danielmeppiel) following the direct product decisions confirmed on 2026-09-30 and explicit authorization to update the issues on 2026-10-01. Daniel separately confirmed that he is the review contact for accepted scopes. This records a human decision, not an autonomous triage recommendation. It does not promise a release, assign implementation, approve a merge, or bypass review.
6. Daniel Meppiel (danielmeppiel)

   added

   status/acceptedHuman scope approval; verify the issue's approval record and review contact before work.Human scope approval; verify the issue's approval record and review contact before work.

   on Oct 1, 2026
7. Bortlesboat commented on Oct 10, 2026

   

   Andrew Barnes (Bortlesboat)

   on Oct 10, 2026

   More actions

   I'd like to work on this. Reproduced the reader-thread crash locally with a child that writes UTF-8 + a non-UTF-8 byte under encoding="gbk". Worth noting that run() then returns stdout='' and stderr=None, so on top of the traceback the output is silently lost.

   Plan within the approved scope: a small helper that runs the install-path git subprocesses with bytes output and decodes stdout/stderr as UTF-8 in the calling thread. Malformed output raises a subprocess.SubprocessError subclass naming the command, so existing failure handling still applies and nothing gets replaced or dropped. I'll switch the text=True git calls under deps/, cache/git_cache.py and utils/git_sparse.py / git_env.py to it, and add a regression test that runs a real child process under a forced cp936 default.