feat(cli): add ability for user to cancle file transfer in CLI via CTRL+C

[LevinCeglie]

This PR implements robust cancelation logic for file transfers via the CLI. With these changes, the user can interrupt file uploads and downloads using CTRL+C (KeyboardInterrupt) and the CLI will gracefully cancel the transfers and still create a summary.

[greptile-apps]

Greptile Summary

This PR adds CLI cancellation support for file transfers. The main changes are:

• Cancellation events passed into upload and download workers.
• Cancel-aware retry waits and transfer callbacks.
• Cleanup logic for interrupted downloads.
• Canceled transfer counts in upload and download summaries.
• Exit code 130 for interrupted CLI transfers.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.
• The latest cleanup logic preserves resumed download data while removing interrupted overwrite output.
• The CLI now reports interrupted transfers and exits with the expected cancellation code.

Important Files Changed

Filename	Overview
cli/kleinkram/api/file_transfer.py	Adds transfer cancellation state, worker cleanup, retry interruption, canceled result states, and partial-file cleanup.
cli/kleinkram/cli/_download.py	Adds canceled download counts to summaries and exits with code 130 after cancellation.
cli/kleinkram/cli/_upload.py	Adds canceled upload counts to summaries and exits with code 130 after cancellation.
cli/kleinkram/errors.py	Adds a cancellation marker error for transfer workers.

_{Reviews (5): Last reviewed commit: "fix(cli): fix data deletion of cleanup d..." | Re-trigger Greptile}

[greptile-apps]

Running workers still block shutdown(wait=False, cancel_futures=True) only cancels work that has not started. Any worker already inside the S3 or HTTP transfer continues running on a non-daemon executor thread, which keeps the Python process alive after the summary is printed and exit code 130 is raised. A Ctrl+C can still appear to hang until those in-flight transfer calls return.

Prompt To Fix With AI

This is a comment left during a code review.
Path: cli/kleinkram/api/file_transfer.py
Line: 681

Comment:
**Running workers still block** `shutdown(wait=False, cancel_futures=True)` only cancels work that has not started. Any worker already inside the S3 or HTTP transfer continues running on a non-daemon executor thread, which keeps the Python process alive after the summary is printed and exit code 130 is raised. A Ctrl+C can still appear to hang until those in-flight transfer calls return.

How can I resolve this? If you propose a fix, please make it concise.

[LevinCeglie]

not an issue, cancel_event is checked every chunk during download and during each boto3_cb callback during upload.

[greptile-apps]

That's a fair point — if cancel_event is checked on every chunk (download) and every boto3_cb callback (upload), in-flight workers will exit their inner loops promptly after the event is set. That does effectively address the blocking concern; shutdown(wait=False) just avoids waiting for the already-cooperating threads to finish their current loop iteration.

I'll withdraw the concern. Thanks for the clarification.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.