fix(audit): force UTF-8 stdout in report.py so it renders on a cp1251 console#105
Merged
Conversation
… console report.py main() prints the rendered markdown/HTML, which carries the glyphs '>=', '·', '—'. On a Windows console using a locale codepage (cp1251 on a Russian-locale box - the STS desktop target's own environment) that print() raises UnicodeEncodeError and the report is lost. Force sys.stdout to UTF-8 before rendering. normalize/score/run_static already print only ASCII json.dumps or write files with encoding=utf-8, so report.py was the lone crash site. Adds a selftest that renders markdown + html to a simulated cp1251 stdout and asserts no crash (report selftest: 34 -> 36 checks). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe report CLI now reconfigures standard output to UTF-8 when supported and adds a self-test that renders markdown and HTML under a simulated cp1251 console to verify non-ASCII glyphs do not fail output. ChangesReport output encoding
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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.
What
report.py main()prints the rendered markdown/HTML health report, which contains≥,·,—. On a Windows console using a locale codepage — cp1251 on a Russian-locale box, which is the STS desktop target's own build/run environment — thatprint()raisesUnicodeEncodeErrorand the report is lost:Fix
Force
sys.stdoutto UTF-8 inmain()before rendering.normalize/score/run_staticalready print only ASCIIjson.dumpsor write files withencoding="utf-8", soreport.pywas the lone crash site.Test
Adds a regression selftest that renders markdown + html to a simulated cp1251 stdout and asserts
main()does not crash (report selftest: 34 → 36checks). Verified on a real cp1251 box:report.py --format markdown(noPYTHONUTF8) now exits 0 and renders the em-dash/≥cleanly — the exact invocation that crashed before.How it was found
Surfaced running
audit/end-to-end on the real STS codebase (STS_new/SectorTS, net472 / WPF / DevExpress): OwnSharp → SARIF →audit/aggregateproduced a correct 380-finding health report, but the markdown render died on the cp1251 console untilPYTHONUTF8=1was forced. This removes the need for that workaround.🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests