Skip to content

Split branding tests into module#1673

Closed
oferchen wants to merge 1 commit into
masterfrom
enforce-maximum-line-count-in-rust-source
Closed

Split branding tests into module#1673
oferchen wants to merge 1 commit into
masterfrom
enforce-maximum-line-count-in-rust-source

Conversation

@oferchen
Copy link
Copy Markdown
Owner

Summary

  • move the branding command test suite into a dedicated submodule to reduce the primary source file length
  • update the workspace manifest include path so the relocated tests continue to validate the expected branding metadata

Testing

  • cargo test -p xtask branding
  • cargo --locked run -p xtask -- enforce-limits

https://chatgpt.com/codex/tasks/task_e_6903503a75a88323be2cb421f2c3f35c

@oferchen oferchen closed this Oct 30, 2025
@oferchen oferchen deleted the enforce-maximum-line-count-in-rust-source branch October 30, 2025 11:56
oferchen added a commit that referenced this pull request May 5, 2026
Defines the empirical benchmark harness, workloads (100 / 1k / 10k
concurrent clients), metrics, soft-limit triggers, comparison oracle
against upstream rsync 3.4.1, and the decision criteria that gate the
async listener migration tracked under #1935. Frames the active-counter
fix from the parent audit (#1673, PR #3705) as a strict precondition.

Tracking: oc-rsync task #1933.
oferchen added a commit that referenced this pull request May 5, 2026
Static analysis of the daemon's accept loop, per-connection resource
cost, hard and soft limits, lock contention surface, and the migration
sequencing against the async listener RFC. Frames the empirical
follow-up benchmark at 100, 1000, and 10000 concurrent connections.

Tracking: oc-rsync task #1673.
oferchen added a commit that referenced this pull request May 5, 2026
)

Defines the empirical benchmark harness, workloads (100 / 1k / 10k
concurrent clients), metrics, soft-limit triggers, comparison oracle
against upstream rsync 3.4.1, and the decision criteria that gate the
async listener migration tracked under #1935. Frames the active-counter
fix from the parent audit (#1673, PR #3705) as a strict precondition.

Tracking: oc-rsync task #1933.
oferchen added a commit that referenced this pull request May 7, 2026
#3895)

Replace the thread-per-connection audit with a focused 5-section
brief covering the accept loop in
crates/daemon/src/daemon/sections/server_runtime/accept_loop.rs,
the per-thread stack and per-session memory ceiling, the fork-vs-thread
trade vs upstream rsyncd, slowloris and lock-contention failure modes,
and the migration path through tokio listener (#1934/#1935),
daemon-level max_connections, and bounded worker pools.
oferchen added a commit that referenced this pull request May 14, 2026
…n gap (#1673) (#4023)

Distil the existing thread-per-connection analysis into a single-page
audit with a concrete threshold table (100/1k/10k) and one
recommendation: a daemon-level max-connections admission cap that reads
the already-wired ConnectionCounter before thread::spawn and returns
upstream's @error: max connections (N) reached.
oferchen added a commit that referenced this pull request May 18, 2026
Static analysis of the daemon's accept loop, per-connection resource
cost, hard and soft limits, lock contention surface, and the migration
sequencing against the async listener RFC. Frames the empirical
follow-up benchmark at 100, 1000, and 10000 concurrent connections.

Tracking: oc-rsync task #1673.
oferchen added a commit that referenced this pull request May 18, 2026
)

Defines the empirical benchmark harness, workloads (100 / 1k / 10k
concurrent clients), metrics, soft-limit triggers, comparison oracle
against upstream rsync 3.4.1, and the decision criteria that gate the
async listener migration tracked under #1935. Frames the active-counter
fix from the parent audit (#1673, PR #3705) as a strict precondition.

Tracking: oc-rsync task #1933.
oferchen added a commit that referenced this pull request May 18, 2026
#3895)

Replace the thread-per-connection audit with a focused 5-section
brief covering the accept loop in
crates/daemon/src/daemon/sections/server_runtime/accept_loop.rs,
the per-thread stack and per-session memory ceiling, the fork-vs-thread
trade vs upstream rsyncd, slowloris and lock-contention failure modes,
and the migration path through tokio listener (#1934/#1935),
daemon-level max_connections, and bounded worker pools.
oferchen added a commit that referenced this pull request May 18, 2026
…n gap (#1673) (#4023)

Distil the existing thread-per-connection analysis into a single-page
audit with a concrete threshold table (100/1k/10k) and one
recommendation: a daemon-level max-connections admission cap that reads
the already-wired ConnectionCounter before thread::spawn and returns
upstream's @error: max connections (N) reached.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant