Repository navigation
test(tui): make mode_probe wait for the status bar before it reads the label - #40
Merged
Merged
Conversation
…e label mode_probe.py read the label in the border of the prompt box (the mode, for example "· always-approve") as soon as the welcome text was on the screen. The label can be drawn a few frames later. A scenario that sends no key (a flag, or a saved config.toml) could then record "(none)". Scenario "config.toml: permission_mode = always-approve", same binary, probe unchanged: v0.5.0 showed the label in 14 of 17 runs and no label in 3; v0.6.0 showed it in 17 of 17. The probe now waits one second after the welcome text, as it already does after each key. With the wait, v0.5.0 showed the label in 37 of 37 runs and v0.6.0 in 13 of 13, and the output of the two builds is identical. Found in V0.6 exit condition 4 (v0.5.0 against the new build, same agent).
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.
Summary
scripts/tui_pty/mode_probe.pyread the label in the border of the prompt box (the mode, for example· always-approve) as soon as the welcome text was on the screen. The label can be drawn a few frames later. A scenario that sends no key (a flag, or a savedconfig.toml) could then record(none). 3 added lines in one script: the probe waits one second after the welcome text, as it already does after each key.obs.ready = term.wait_for(r"Thanks for trying zypi", 25) +term.pump(1.0) # new: the label can come a few frames after the welcome text for key in scenario.keys: term.send(key) term.pump(1.0) obs.label = status_label(term.text())Found in V0.6 exit condition 4 (v0.5.0 against the new build, same Python agent). The tables of the two builds differed in one row,
config.toml: permission_mode = always-approve:label=(none)for v0.5.0 andlabel=· always-approvefor v0.6.0. No code that draws the label changed between the two tags (git diff v0.5.0 main -- tui/cratesadds no line that names a permission mode), so the probe was the suspect. Repeat runs of that one scenario show it.Evidence
Before (scenario
config.toml: permission_mode = always-approve, one binary per row, probe unchanged):The same v0.5.0 binary gives both answers, so the answer is not a property of the build.
After (probe with the wait): v0.5.0 shows the label in 37 of 37 runs, v0.6.0 in 13 of 13. The whole output of
mode_probe.py(15 lines: 10 scenarios, 4 refused values, the settings page) is identical for the two builds;diffof the two outputs is empty.ruff check .andruff format --check .pass.scripts/tests/test_tui_pty.py: 59 passed / 8 skipped on Windows (the PTY parts skip there). The changed code is inobserve(), which needs a Linux pty; the runs above (WSL, Linux) test it.Merge Danger
Door: two-way.
Blast Radius: one manual test script (
scripts/tui_pty/; no workflow runs it). No product code. A run of the probe takes about 10 s longer (1 s for each of the 10 scenarios).