omarchy-send/internal
28allday 6e7aac090c Stop a cancelled transfer from carrying on into the next one
When the receiver cancelled a transfer partway through, the sender kept
uploading the remaining files of that batch (the loop continued past the
failure), and a newly started transfer never stopped the old goroutine —
so the old, cancelled transfer appeared to "carry on".

Fixes:
- Each send now runs under a cancellable context. A new transfer to a peer
  supersedes (cancels) any still-running send to that same peer.
- A network/session error mid-batch aborts the rest of the batch, emitting
  a clean Cancel for the un-sent files instead of pushing them anyway. A
  local file-open error still skips only that file.
- Bounded connection timeouts (dial 10s, TLS 10s, response-header 30s) so a
  vanished peer fails fast; the overall timeout stays off for large files.

Test: a receiver whose session is gone (returns 403) causes the sender to
make exactly one upload attempt and then abort, reporting the rest cancelled.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 21:20:30 +01:00
..
app Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
client Stop a cancelled transfer from carrying on into the next one 2026-05-27 21:20:30 +01:00
config Generate a random friendly alias on first run 2026-05-27 20:44:55 +01:00
dbg Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
discovery Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
protocol Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
security Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
server Support sending folders, not just single files 2026-05-27 21:00:52 +01:00
theme Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
transfer Initial commit: Omarchy-Send v0.1.0 2026-05-27 19:26:08 +01:00
tui Support sending folders, not just single files 2026-05-27 21:00:52 +01:00