Bound the FTP connections allod site deploy opens #187

Merged

vnprc merged 3 commits from agent/site-ftp-concurrency into master

2026-09-10 21:56:23 +01:00

allod-agent commented

2026-09-10 19:23:31 +01:00

Member

allod site deploy now runs its rclone sync with two transfers, two checkers, --check-first, and at most three simultaneous FTP connections per rclone filesystem instance, instead of rclone's defaults of four, eight, and unlimited. That is what made a one-page deploy fail partway through on shared hosting: directory listings during the check phase opened more connections than the host allows per client, and the refused connections surfaced as a TLS handshake error on a mkdir. With --check-first the listing phase finishes before any file moves. The backup directory on the same remote is a second instance with its own pool, so the worst case for a deploy is six connections. --dry-run gets the same budget. Build, filter, backup directory, verification, and the credential stanza are unchanged. A test pins the exact sync argument list for a normal deploy, the public-html profile, and a dry run, and removing any of the four flags fails it. A live sync against a real host was not run from here; the next real deploy is the proof, and if a host allows fewer than six connections the constants at the top of the deploy code are where to lower it.

Closes allod/tools#186. Closes allod/tools#184.

What changed

cmd/allod/site.go: constants for transfers and checkers, with the concurrency derived as one more than the larger of the two, which is the rule rclone's FTP documentation gives for a sync run with --check-first (quoted in the comment); the sync argument list carries --transfers, --checkers, --ftp-concurrency, and --check-first after --verbose; the deploy help states the per-instance bound and the two-instance worst case.
cmd/allod/site_test.go: the deploy tests compare the whole argument list, and the dry-run test asserts it matches a real deploy's plus --dry-run.

Risk

R1. The values are fixed, not per host. A host that allows fewer than six connections per client can still fail the same way; making the numbers a hosting-profile field is the follow-up if that host appears. Not run: a sync against a real hosting account; the two-instance worst case is derived from rclone's documented behaviour, not observed.

Validation

gofmt -l cmd/allod/ empty; go vet and go test pass in both build shapes, re-run by the integrator on the final commit.
nix flake check passes.
Sabotage: dropping --ftp-concurrency (first round) and --check-first (second round) each fail the three deploy argument-list tests; restored and green.
Reviewed by codex (gpt-5.6-sol) and pi (gpt-oss-120b) on the first and final diffs. Applied from the first round: the per-instance cap and the --check-first budget. Rejected: pi's claim that the rule is "at least the sum" (the docs say one more), and the dry-run test copying the temporary filter path, which is the existing convention.

Labels are unavailable to this token; none is warranted.

`allod site deploy` now runs its rclone sync with two transfers, two checkers, `--check-first`, and at most three simultaneous FTP connections per rclone filesystem instance, instead of rclone's defaults of four, eight, and unlimited. That is what made a one-page deploy fail partway through on shared hosting: directory listings during the check phase opened more connections than the host allows per client, and the refused connections surfaced as a TLS handshake error on a `mkdir`. With `--check-first` the listing phase finishes before any file moves. The backup directory on the same remote is a second instance with its own pool, so the worst case for a deploy is six connections. `--dry-run` gets the same budget. Build, filter, backup directory, verification, and the credential stanza are unchanged. A test pins the exact sync argument list for a normal deploy, the public-html profile, and a dry run, and removing any of the four flags fails it. A live sync against a real host was not run from here; the next real deploy is the proof, and if a host allows fewer than six connections the constants at the top of the deploy code are where to lower it. Closes allod/tools#186. Closes allod/tools#184. ## What changed - `cmd/allod/site.go`: constants for transfers and checkers, with the concurrency derived as one more than the larger of the two, which is the rule rclone's FTP documentation gives for a sync run with `--check-first` (quoted in the comment); the sync argument list carries `--transfers`, `--checkers`, `--ftp-concurrency`, and `--check-first` after `--verbose`; the deploy help states the per-instance bound and the two-instance worst case. - `cmd/allod/site_test.go`: the deploy tests compare the whole argument list, and the dry-run test asserts it matches a real deploy's plus `--dry-run`. ## Risk R1. The values are fixed, not per host. A host that allows fewer than six connections per client can still fail the same way; making the numbers a hosting-profile field is the follow-up if that host appears. Not run: a sync against a real hosting account; the two-instance worst case is derived from rclone's documented behaviour, not observed. ## Validation - `gofmt -l cmd/allod/` empty; `go vet` and `go test` pass in both build shapes, re-run by the integrator on the final commit. - `nix flake check` passes. - Sabotage: dropping `--ftp-concurrency` (first round) and `--check-first` (second round) each fail the three deploy argument-list tests; restored and green. - Reviewed by codex (gpt-5.6-sol) and pi (gpt-oss-120b) on the first and final diffs. Applied from the first round: the per-instance cap and the `--check-first` budget. Rejected: pi's claim that the rule is "at least the sum" (the docs say one more), and the dry-run test copying the temporary filter path, which is the existing convention. Labels are unavailable to this token; none is warranted.

allod-agent added 3 commits

2026-09-10 19:23:31 +01:00