fix(web,vis): do not crash printing the startup banner on legacy console codecs - #2577
Open
ayaangazali wants to merge 1 commit into
Open
fix(web,vis): do not crash printing the startup banner on legacy console codecs#2577ayaangazali wants to merge 1 commit into
ayaangazali wants to merge 1 commit into
Conversation
…ole codecs print_banner writes the banner with bare print(), and both the web and vis banners include U+279C. On a console whose codec cannot represent it (GBK on Chinese Windows, for example) that raises UnicodeEncodeError. The banner is printed before the server binds its port, so the unhandled error took the whole process down and nothing ended up listening. Characters the stdout encoding cannot represent are now replaced. The substitution happens before the box width is measured so the borders still line up, and terminals that can render the glyph are unaffected.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issue
Resolve #2532
Description
print_bannerinsrc/kimi_cli/utils/server.pywrites the banner with a bareprint(), and both callers put U+279C in front of each URL (web/app.py:374,376andvis/app.py:128). On a console whose codec cannot represent that character, GBK on Chinese Windows being the reported case, the print raisesUnicodeEncodeError.The part that makes it more than cosmetic: the banner is printed before the server binds its port, so the unhandled error takes the process down and nothing ends up listening. From the user side that shows up as a Web UI stuck on WebSocket errors rather than as a crash, which makes it a confusing one to diagnose.
Characters the current stdout encoding cannot represent are now replaced instead of raising. Two details worth mentioning:
I deliberately did not touch
sys.stdoutreconfiguration or add an env var. Both would fix the symptom globally but change behavior well outside this banner, and the crash only needs the one guard where both callers already funnel through.The issue was filed against 1.43.0; I verified the same code path is still there at HEAD (4a550ef, 1.49.0).
Checklist
make gen-changelogto update the changelog. (hand-edited CHANGELOG.md in the same style, I do not have the Kimi API setup the skill needs)make gen-docsto update the user documentation. (nothing in docs covers banner rendering)Note on gates:
make check-kimi-cliis clean andmake test-kimi-clipasses. One PTY e2e test (test_shell_mode_toggle_roundtrip) flaked once under full suite load on my machine; it passes in isolation on both this branch and unmodified main, and the full e2e suite passes on re-run, so it looks like timing rather than anything from this change.small disclosure as usual: freshman, no Windows machine to hand so I reproduced the encoding failure by rendering the banner through a gbk stream rather than on real hardware. logic decisions talked through with claude code. if you would rather just swap the arrow for an ascii character and skip the helper entirely, that is a totally fair call and i am happy to redo it that way :)