--retries=N — number of attempted retries for a failed connection
Current FastSync behavior: src/shared/transport_tcp.c creates blocking sockets with no timeout. receive_n_data() in src/shared/protocol.c can block forever on a stalled connection. There are no TCP keepalive options and no retry logic.
Config fields: int io_timeout_sec, int connect_timeout_sec, int connect_retries
Implementation:
Use SO_RCVTIMEO/SO_SNDTIMEO or poll() with timeout in send_n_data/receive_n_data
Apply SO_KEEPALIVE and optional TCP_USER_TIMEOUT on Linux
Retry TCP/SSH connection up to --retries with exponential backoff
For SSH transport, detect failed execvp (already partially handled via exec_pipe) and retry
Protocol: no wire changes; client-side robustness only
Priority: high Rationale: Without timeouts, a single hung connection can stall a sync job indefinitely. Retries are essential for automation over unreliable networks.
Acceptance criteria:
--timeout=30 causes a stalled receive to error out after 30 seconds
--contimeout=10 fails fast when the server is unreachable
--retries=3 attempts the connection three times before failing
Integration tests simulate slow/stalled server and verify timeout behavior
**Corresponding rsync flags/behavior:**
- `--timeout=SECONDS` — I/O timeout
- `--contimeout=SECONDS` — connection timeout
- `--retries=N` — number of attempted retries for a failed connection
**Current FastSync behavior:**
`src/shared/transport_tcp.c` creates blocking sockets with no timeout. `receive_n_data()` in `src/shared/protocol.c` can block forever on a stalled connection. There are no TCP keepalive options and no retry logic.
**Proposed changes:**
- CLI flags: `--timeout=<sec>`, `--contimeout=<sec>`, `--retries=<n>`
- Config fields: `int io_timeout_sec`, `int connect_timeout_sec`, `int connect_retries`
- Implementation:
- Use `SO_RCVTIMEO`/`SO_SNDTIMEO` or `poll()` with timeout in `send_n_data`/`receive_n_data`
- Apply `SO_KEEPALIVE` and optional TCP_USER_TIMEOUT on Linux
- Retry TCP/SSH connection up to `--retries` with exponential backoff
- For SSH transport, detect failed `execvp` (already partially handled via exec_pipe) and retry
- Protocol: no wire changes; client-side robustness only
**Priority:** high
**Rationale:** Without timeouts, a single hung connection can stall a sync job indefinitely. Retries are essential for automation over unreliable networks.
**Acceptance criteria:**
- [ ] `--timeout=30` causes a stalled receive to error out after 30 seconds
- [ ] `--contimeout=10` fails fast when the server is unreachable
- [ ] `--retries=3` attempts the connection three times before failing
- [ ] Integration tests simulate slow/stalled server and verify timeout behavior
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Corresponding rsync flags/behavior:
--timeout=SECONDS— I/O timeout--contimeout=SECONDS— connection timeout--retries=N— number of attempted retries for a failed connectionCurrent FastSync behavior:
src/shared/transport_tcp.ccreates blocking sockets with no timeout.receive_n_data()insrc/shared/protocol.ccan block forever on a stalled connection. There are no TCP keepalive options and no retry logic.Proposed changes:
--timeout=<sec>,--contimeout=<sec>,--retries=<n>int io_timeout_sec,int connect_timeout_sec,int connect_retriesSO_RCVTIMEO/SO_SNDTIMEOorpoll()with timeout insend_n_data/receive_n_dataSO_KEEPALIVEand optional TCP_USER_TIMEOUT on Linux--retrieswith exponential backoffexecvp(already partially handled via exec_pipe) and retryPriority: high
Rationale: Without timeouts, a single hung connection can stall a sync job indefinitely. Retries are essential for automation over unreliable networks.
Acceptance criteria:
--timeout=30causes a stalled receive to error out after 30 seconds--contimeout=10fails fast when the server is unreachable--retries=3attempts the connection three times before failing