Skip to content

[FEATURE] Implement Transaction Abort Logic #98

@Firstp1ck

Description

@Firstp1ck

Summary

Implement transaction abort functionality in the PreflightExec modal. Currently, pressing 'x' only shows a toast message but doesn't actually abort the running PTY process that executes package operations (install/remove/downgrade/update).

Files to modify

  • src/events/modals/common.rs (around line 256)
  • src/app/runtime/workers/executor.rs (communication and abort signaling)
  • src/app/runtime/channels.rs (add abort channel)

Expected behavior

When users press 'x' in the PreflightExec modal during execution:

  1. Signal the executor worker to abort the current operation
  2. Kill the running PTY child process gracefully
  3. Clean up any temporary resources and file handles
  4. Show appropriate feedback about the aborted operation
  5. Return to a safe state allowing retry or cancellation

Implementation approach

  1. Add abort signaling infrastructure:

    • Add an abort channel to the Channels struct
    • Pass abort receiver to executor worker
    • Send abort signal from UI when 'x' is pressed
  2. Modify PTY execution:

    • Check for abort signal in the execution loop
    • Kill child process when abort is requested
    • Handle cleanup and proper exit
  3. Update UI state:

    • Transition modal to appropriate state after abort
    • Show clear user feedback about aborted operation
    • Handle edge cases (process already finished, abort failed, etc.)

Testing

  • cargo check passes
  • cargo clippy --all-targets --all-features -- -D warnings passes
  • cargo test -- --test-threads=1 passes
  • Test abort during install operations
  • Test abort during remove operations
  • Test abort during long-running operations
  • Test abort when process finishes naturally (race condition)
  • Test multiple abort attempts
  • Test abort cleanup and resource management

Additional context

The current PTY execution uses portable_pty and runs bash commands in a spawned child process. The executor worker runs in a separate tokio task, so implementing abort requires inter-task communication. Follow the existing channel patterns used for other executor communications.

Key considerations:

  • Handle race conditions between process completion and abort requests
  • Ensure proper cleanup of PTY resources and file descriptors
  • Provide clear user feedback for different abort scenarios
  • Maintain compatibility with existing dry-run functionality
  • Consider platform differences (Unix vs Windows execution)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions