Skip to content

docs(audits): re-verify tokio dependency boundary#3706

Merged
oferchen merged 1 commit into
masterfrom
docs/tokio-boundary-reverify-2026
May 5, 2026
Merged

docs(audits): re-verify tokio dependency boundary#3706
oferchen merged 1 commit into
masterfrom
docs/tokio-boundary-reverify-2026

Conversation

@oferchen
Copy link
Copy Markdown
Owner

@oferchen oferchen commented May 5, 2026

Summary

  • Re-verifies the tokio dependency scope set by audit Modularize CLI drive orchestration helpers #1779 against the current Cargo.toml set after Add zlib accessor coverage to boost test totals #1732 (async default) and Fix Windows PATHEXT parsing for fallback binary search #1818 (post-default refactors).
  • Documents that the original "only daemon and core" framing has drifted to seven justified consumers: daemon, core, engine, transfer, bandwidth, protocol, rsync_io. Each is gated behind async or embedded-ssh, with file:line citations.
  • Inventories the entire pub async fn / pub fn ... -> impl Future surface (14 items) and confirms it lives only in the seven allowed crates - the public API boundary still holds.
  • Proposes a CI guardrail (tools/ci/check_tokio_boundary.sh) that fails on accidental expansion and a corresponding policy text update.

Pure docs change. No code or Cargo.toml edits.

Test plan

  • Sanity-read the per-crate table for accuracy (file:line refs match).
  • Confirm the seven-crate allow-list is acceptable as the new policy baseline.
  • Decide whether to follow up with tools/ci/check_tokio_boundary.sh in a separate PR.

Re-checks the tokio scope established by audit #1779 against the
current Cargo.toml set after #1732 (async became default) and
#1818. Documents drift to seven allowed consumers (daemon, core,
engine, transfer, bandwidth, protocol, rsync_io), proves the
public async surface stays in those crates, and proposes a CI
guardrail script to pin the boundary.
@oferchen oferchen merged commit b43a566 into master May 5, 2026
8 checks passed
@github-actions github-actions Bot added the documentation Improvements or additions to documentation label May 5, 2026
oferchen added a commit that referenced this pull request May 5, 2026
Refresh the async migration roadmap to reflect the seven-crate
tokio surface ratified by the boundary re-verification audit
(#3706). Replaces the earlier 5-phase sketch with a 6-phase plan
ordered around concrete code-grounded entry points.

Phase 0 wires a CI guardrail; Phase 1 ratifies the seven crates;
Phases 2-4 promote feature-gated async paths to default for the
daemon listener, SSH transport, and receiver pipeline; Phase 5
finalises the rayon-tokio composition. Each phase carries a
build-time feature flag and a runtime kill switch, with four
exit gates per rollout: wire compatibility, performance, line
coverage, and interop.

Cites the new tokio dependency boundary audit, the daemon
thread-per-connection scalability audit, and the related design
notes for channel abstraction, the daemon accept loop, and
io_uring-rayon composition.
@oferchen oferchen deleted the docs/tokio-boundary-reverify-2026 branch May 6, 2026 18:57
oferchen added a commit that referenced this pull request May 18, 2026
Re-checks the tokio scope established by audit #1779 against the
current Cargo.toml set after #1732 (async became default) and
#1818. Documents drift to seven allowed consumers (daemon, core,
engine, transfer, bandwidth, protocol, rsync_io), proves the
public async surface stays in those crates, and proposes a CI
guardrail script to pin the boundary.
oferchen added a commit that referenced this pull request May 18, 2026
Refresh the async migration roadmap to reflect the seven-crate
tokio surface ratified by the boundary re-verification audit
(#3706). Replaces the earlier 5-phase sketch with a 6-phase plan
ordered around concrete code-grounded entry points.

Phase 0 wires a CI guardrail; Phase 1 ratifies the seven crates;
Phases 2-4 promote feature-gated async paths to default for the
daemon listener, SSH transport, and receiver pipeline; Phase 5
finalises the rayon-tokio composition. Each phase carries a
build-time feature flag and a runtime kill switch, with four
exit gates per rollout: wire compatibility, performance, line
coverage, and interop.

Cites the new tokio dependency boundary audit, the daemon
thread-per-connection scalability audit, and the related design
notes for channel abstraction, the daemon accept loop, and
io_uring-rayon composition.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant