Test that a diff's path and content are sanitized before they render
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
Research direction
Read the diff rendering paths in src/render.ts and the existing runner cases in test/render.test.ts; trace how the diff and note views draw edit paths and file content. Add cases for escape sequences and carriage returns in both inputs, then assert rendered lines contain no control characters and carriage returns become newlines. Confirm each case fails when its corresponding sanitize call is removed.
Written by the indexing model from the issue text.
Description
Problem
src/render.ts passes each edit diff's path and diff through sanitize before drawing them, so a string from a file or the daemon cannot drive the terminal. test/render.test.ts covers sanitizing the tool's text result, but no test covers the diff fields. If the sanitize calls in the diff preview were dropped, every suite would still pass.
path comes from the tool call's arguments and diff is built from file contents, so both can carry control sequences (for example a file name or file content holding \x1b] or \r). The one-line note is fixed text built in src/diff.ts, so it needs no sanitizing, but the path drawn beside it does.
Proposal
Add render suite cases, driven through Pi's runner as the existing render cases are, where:
- an edit's path holds an escape sequence and a carriage return, for both the diff view and the note view
- the file content behind the diff holds the same
Assert that the drawn lines hold no control characters and that a carriage return became a newline. Check that each case fails when its sanitize call is removed.
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 1
- Avg merge
- 10h 45m
- Merged PRs (30d)
- 20
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from gortexhq/pi
-
dependencies
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 1-2 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
components-web-app/docs#307 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
localstack/localstack-mcp-server#112 ·
Maintainers usually reply within 1 day
-
area:frontend kind:bug priority:p1 ready
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
bug ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
PhyberApex/kuroshiro#1687 ·
Maintainers usually reply within 1 day
-
Performance (Web Vitals) collector: LCP/FCP from background tabs are not discarded, inflating p75Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
umami-software/umami#4720 ·
Maintainers usually reply within 3 days