Add deterministic terminal transcript replay and stream tests
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 68/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- bash, typescript
Research direction
Start by reading the existing line-tracker and suggestion-controller tests and helpers in the frontend logic to learn the replay interfaces. Create sanitised Bash, IOS-XE, NX-OS and TMOS transcript fixtures with synthetic secrets, then write deterministic replay tests using fake clocks and varied chunking. Done means all acceptance criteria pass: equivalent final state across chunk boundaries, no leaked secrets, and a reproducible command to add new transcripts.
Written by the indexing model from the issue text.
Description
Goal
Protect prompt detection and suggestions against realistic asynchronous terminal output without requiring live network devices.
Priority
6 of 6 in the testing improvement backlog. Raise priority if prompt/suggestion stream regressions become a frequent reported problem. Independent of native desktop automation for most cases.
Current gap
Existing line-tracker and suggestion-controller tests cover many specific cases. A reusable set of representative terminal transcripts replayed under varied chunking/timing would extend this protection across realistic device exchanges.
Scope
Create a small reviewed set of sanitised or synthetic Bash, IOS-XE, NX-OS and TMOS transcripts. Include prompt/mode changes, line editing, output bursts and interactive/secret exchanges. Run most scenarios against existing frontend logic with controlled clocks.
Acceptance criteria
- Fixtures contain no real credentials, tokens, sensitive hostnames/addresses or unnecessary personal data; secret examples are synthetic.
- Replay equivalent streams with different byte/chunk boundaries, including splits within escape sequences and multibyte text where supported.
- Assert equivalent final reconstructed line, prompt/mode and suggestion state for equivalent output and input schedules.
- Cover delayed partial prompts without premature detection and explicitly test timing-sensitive cases against the intended idle rules.
- Cover large output bursts and verify suggestions remain appropriately suppressed.
- Cover backspace, carriage-return redraws and reconciliation with observed remote echo.
- Cover secret prompts and verify synthetic secret input does not enter suggestion state or captured logs, with recovery at the next normal prompt.
- Cover interactive/full-screen-style output and verify required input passes through without spurious completions.
- Use fake clocks and deterministic schedules rather than real sleeps or unseeded randomness.
- Provide a reproducible command and a concise way to add a transcript when a new device regression is reported.
Boundaries
Reuse existing line-tracker/controller tests and helpers; do not introduce a second terminal parser or full device emulator. These logic tests complement, not replace, a few native terminal smoke checks. Chunk-boundary equivalence must not assume that intentional changes in idle timing produce identical intermediate states.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 6h 51m
- Merged PRs (30d)
- 68
Getting set up
- No Dockerfile or Docker Compose file
- No 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 bonzo81/comnd
-
p3 testing
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
maintenance p3 testing
Difficulty 3/5 1-2 days Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
enhancement p3
Difficulty 4/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
appandflow/stim#5258 ·
Maintainers usually reply within 1 day
-
area/docs framework/hugo help wanted language/markdown
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 68/100
lingdojo/kana-dojo#33660 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
drizzle-team/drizzle-orm#6639 ·
Maintainers usually reply within 4 days
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100