"concurrency: auto" is a hardcoded 4, not adaptive; the name promises something it does not do

[eiserv]

What

advanced.concurrency and advanced.request_concurrency accept the literal string auto (autoInt in internal/config/configfile.go, and the schema's autoInt definition). auto resolves to a compile-time constant:

defaultConcurrency        = 4
defaultRequestConcurrency = 16

via autoInt.or(def). So auto means "4" and "16", always, on every runner and every link.

Why it matters

Two separate problems, one cosmetic and one real.

The word is misleading. auto promises that easySFTP works something out. It does not; it is a synonym for "unset". docs/configuration.md is honest about it (auto (4)), but a user reading only the config file or the JSON schema reasonably concludes that easySFTP adapts to the runner and does not need tuning. That is exactly the user who will never touch the value and never find out that it was a fixed 4 the whole time.

The fixed value is a poor fit for the spread of environments. A standard hosted runner has 4 vCPUs; a larger runner has 16 or 64. Link characteristics vary far more than that: a deploy to a server one datacentre away and a deploy to shared hosting three continents away want very different amounts of parallelism, and 4 concurrent files with 16 in-flight requests each is conservative for the first and possibly too aggressive for the second.

Suggested direction

Pick one of these deliberately and write down which:

1. Make auto mean something. For concurrency, deriving from runtime.NumCPU() is easy but wrong-headed: upload parallelism is bounded by the server and the link, not by the runner's CPU. A genuinely adaptive version would ramp concurrency up while throughput improves and back off on errors, which is real work and needs the measurement harness from the benchmarking issue first.
2. Rename it. default says exactly what it does today and makes no promise. This is the honest, cheap option, at the cost of a config-file compatibility shim for anyone already writing auto.
3. Keep auto, and make the docs and the schema description say plainly that it is a fixed built-in default, not an adaptive one. Cheapest of all, and closes the misleading-name problem without touching behaviour.

Option 3 is probably the right first move, with option 1 revisited only if measurement shows the defaults are actually costing users throughput.

Depends on the performance-baseline issue for anything beyond option 3: changing a default without a number is guessing.

[nickolep]

The benchmark work that landed after this issue now provides the missing decision tool.

Current main measures an explicit auto[] run per scenario/profile, records the settings selected by the binary itself, and reports "policy regret" against the fastest cell in the same sweep. That means option 1 can now be evaluated instead of guessed.

The last stored matrix before that auto[] reporting landed is still directional evidence. On commit 5b23cba, baseline RTT about 13 ms, one repeat, the current fixed coordinate (connections 1, concurrency 4) was slower than the best cell by:

• small: 217.7% (13,670 ms vs 4,303 ms)
• calib-100x64k: 128.9% (17,688 ms vs 7,729 ms)
• large: 71.7% (81,829 ms vs 47,665 ms)
• sync: 13.4% (1,168 ms vs 1,030 ms)
• single: 1.0% (84,457 ms vs 83,614 ms)

The canary spread was 12% and the grid had one repeat, so these are not release-grade thresholds. They are enough to show that one fixed value is not uniformly good.

Recommended next check: run the current matrix on at least baseline, +50ms, baseline/5mbit and +50ms/5mbit, with 3 repeats and the small, large, single, calibration and sync scenarios. Use the generated auto[] regret table as the acceptance criterion. A policy within roughly 15% on every profile is defensible; otherwise keep the conservative fixed defaults and document auto as the built-in default, which the current docs already do.