TUI tests: verify cancelling secret drafts leaves the vault unchanged

Open Beginner friendly
  • Is something wrong?
#809 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@vshalpnjabi is already working on this.

Since Nov 5, 2026.

  • #810 by @vshalpnjabi — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
cli, security, testing

Research direction

Start with secret_modal_key_events in crates/cli/src/tui/events.rs and secret_modal_edit_lifecycle in crates/cli/src/tui/app.rs; reuse the nearby isolated store and MemoryKeychain fixtures. Drive create and edit cancellation through handle_key_event, then verify persisted values and version counts, plus the fields when reopening each dialogue. Run cargo test -p sotto-cli tui:: and cargo fmt --all --check; done means the cancellation cases preserve vault state and the save control still adds the expected version.

Written by the indexing model from the issue text.

Description

good first issue help wanted test-coverage

The problem

Cancelling a secret draft in the dashboard should discard it without writing to the vault. The existing keyboard test opens an edit dialogue and immediately presses Escape, then checks only that the dialogue closed. It never changes the draft before cancelling or checks the stored value and version history afterwards.

Add regression coverage for this existing behaviour. This is a test-coverage task, not a claim that cancellation currently saves a draft.

Evidence and starting points

Inspected a clean checkout of main at 24c48b0e876b89029fa7013101ffb44d46fa4dab:

  • secret_modal_key_events exercises creation and saving, but its cancellation check only asserts show_secret_modal == false after opening an unchanged edit dialogue.
  • close_secret_modal closes the dialogue and clears its draft name and value. The Escape branch in handle_key_event calls it.
  • secret_modal_edit_lifecycle covers a successful save, not cancellation. Nearby tests show how to assert both stored values and app.secret_history(...) with an isolated store and MemoryKeychain.

Verified through source and test inspection on macOS. Rust tests and an interactive terminal session were not run for this issue. Existing open/closed issues and open PRs were checked for overlap.

Proposed approach

Extend the existing TUI tests using synthetic values and the current in-memory fixtures. Drive cancellation through handle_key_event so the tests protect the user's Escape action, not just the close helper in isolation. No network, system keychain or clipboard access is needed.

Acceptance criteria

  • Cancel creation: open New through the keyboard handler, enter a valid unused name and non-empty value, then press Escape. The dialogue closes, the dashboard keeps running, and querying the underlying vault confirms that the draft was not created and the existing entries are unchanged.
  • Cancel editing: seed an existing secret, open Edit through the keyboard handler, change its draft value, then press Escape. The original stored bytes and version-history count remain unchanged. Check persistence through the app/store, not only the cached dashboard list.
  • Reopen after cancellation: reopening New starts with empty fields; reopening Edit loads the original stored value rather than the discarded draft. If the previous draft was unmasked, the reopened dialogue starts masked as it does today.
  • Include a control showing that editing the value and pressing Enter still saves it and adds the expected version. Reuse or strengthen the existing save test rather than duplicating it unnecessarily.
  • Keep this focused on cancellation and its regression tests. Do not add a confirmation prompt, change shortcut behaviour, alter secret-name rules or modify cryptography.

Run cargo test -p sotto-cli tui:: and cargo fmt --all --check. The cancellation assertions should detect an accidental save on Escape, including an extra version even if its value matches the original.

This is suitable for a first contribution because the fixtures and save-path tests already exist. Follow CONTRIBUTING.md and sign off commits with git commit -s.

Dominant language
Rust
Stars
31
Forks
42
Avg merge
2d 18h
Merged PRs (30d)
142

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsotto/sotto

All issues in getsotto/sotto

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.