Add server configuration scaffolding#2209
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ) -> io::Result<i32> { | ||
| Err(io::Error::new( | ||
| io::ErrorKind::Unsupported, | ||
| "receiver role is not yet implemented", | ||
| )) |
There was a problem hiding this comment.
Server mode now always exits unsupported
When rsync --server is invoked, run_server_stdio dispatches to run_receiver/run_generator, but both functions immediately return io::ErrorKind::Unsupported (see run_receiver here and the analogous generator stub below), so run_server_mode emits a “server I/O error” and returns exit code 1 for every server role. The previous implementation delegated to the upstream rsync fallback binary and could complete transfers; after this change all remote --server handshakes will fail even if a fallback binary is installed.
Useful? React with 👍 / 👎.
) Verify that PR #4154 (SSH socketpair stderr drain shutdown + russh ~/.ssh/config support) has restored SSH push and daemon push out of the pre-fix harness timeout, and that no other transfer mode regressed. Data source is benchmark workflow run 25964839057 on tag v0.6.2 at SHA c99bbbc (the PR #4154 commit itself). SSH push 1.29x slower than upstream on initial sync, daemon push 1.33x slower. Both modes recovered from the prior 120 s / 30 s harness timeouts seen in the v0.6.1 release benchmark appendix; the remaining gap to the "SSH on par" and "daemon 2x faster" targets is pre-existing and unrelated to this fix.
Audit the sender-side INC_RECURSE capability gate, document the current disable mechanism, summarise the perf instrumentation that landed under tasks #2196-#2200, cross-reference the SSH and daemon push perf verification from #2209, and lay out the re-enable criteria for the eventual flip of inc_recursive_send from false to true. Recommendation: defer the flip until a 1M-file Mode C push profile run publishes I1-I5 totals alongside hyperfine wall-clock, and the gating criteria from docs/investigations/inc-recurse-sender-regression.md section 5 are met on two consecutive nightly runs. Includes a five-step plan for the eventual flip PR; the flip itself is out of scope here.
) Verify that PR #4154 (SSH socketpair stderr drain shutdown + russh ~/.ssh/config support) has restored SSH push and daemon push out of the pre-fix harness timeout, and that no other transfer mode regressed. Data source is benchmark workflow run 25964839057 on tag v0.6.2 at SHA f58e6df (the PR #4154 commit itself). SSH push 1.29x slower than upstream on initial sync, daemon push 1.33x slower. Both modes recovered from the prior 120 s / 30 s harness timeouts seen in the v0.6.1 release benchmark appendix; the remaining gap to the "SSH on par" and "daemon 2x faster" targets is pre-existing and unrelated to this fix.
Audit the sender-side INC_RECURSE capability gate, document the current disable mechanism, summarise the perf instrumentation that landed under tasks #2196-#2200, cross-reference the SSH and daemon push perf verification from #2209, and lay out the re-enable criteria for the eventual flip of inc_recursive_send from false to true. Recommendation: defer the flip until a 1M-file Mode C push profile run publishes I1-I5 totals alongside hyperfine wall-clock, and the gating criteria from docs/investigations/inc-recurse-sender-regression.md section 5 are met on two consecutive nightly runs. Includes a five-step plan for the eventual flip PR; the flip itself is out of scope here.
) Verify that PR #4154 (SSH socketpair stderr drain shutdown + russh ~/.ssh/config support) has restored SSH push and daemon push out of the pre-fix harness timeout, and that no other transfer mode regressed. Data source is benchmark workflow run 25964839057 on tag v0.6.2 at SHA d8e0e70 (the PR #4154 commit itself). SSH push 1.29x slower than upstream on initial sync, daemon push 1.33x slower. Both modes recovered from the prior 120 s / 30 s harness timeouts seen in the v0.6.1 release benchmark appendix; the remaining gap to the "SSH on par" and "daemon 2x faster" targets is pre-existing and unrelated to this fix.
Audit the sender-side INC_RECURSE capability gate, document the current disable mechanism, summarise the perf instrumentation that landed under tasks #2196-#2200, cross-reference the SSH and daemon push perf verification from #2209, and lay out the re-enable criteria for the eventual flip of inc_recursive_send from false to true. Recommendation: defer the flip until a 1M-file Mode C push profile run publishes I1-I5 totals alongside hyperfine wall-clock, and the gating criteria from docs/investigations/inc-recurse-sender-regression.md section 5 are met on two consecutive nightly runs. Includes a five-step plan for the eventual flip PR; the flip itself is out of scope here.
Summary
Testing
Codex Task