Problem
The current DownloadPlanBuilder uses a single threshold: when the combined download size of all chain (delta) packages reaches 80% of the best full package size, it switches to the full package, discarding all chain packages.
This 80% threshold has several issues:
-
Ignores package count. A user with 2 large chain packages close to full size would overpay (e.g., 850 MB chain vs 1 GB full — user pays +150 MB for no reason). Conversely, 20 small chain packages well below the size threshold would still apply — creating 20 points of failure.
-
Runtime fallback already exists. Each chain package is already paired with a pre-downloaded FallbackFull. If a chain patch fails at runtime, the system automatically falls back to the full package. An overly eager download-stage switch is unnecessary.
-
Absolute overpay can be huge. 20% of a 2 GB full package is 400 MB — a significant extra download for users on metered/slow connections.
Solution
Replace with a count-first heuristic:
| Condition |
Trigger |
Chain count > MaxChainBeforeFallback (default 8) |
→ full package |
| Combined chain size >= full package size |
→ full package |
This prioritizes reliability (fewer packages = fewer failure points) while the size comparison acts as a hard guardrail (never download more than necessary).
MaxChainBeforeFallback is configurable via UpdateConfiguration — set to 0 to disable count-based fallback entirely.
Changes
UpdateConfiguration: add MaxChainBeforeFallback (default 8)
DownloadPlanBuilder.Build(): new count-first + size guardrail logic
ClientStrategy: plumb MaxChainBeforeFallback through
- Tests: 5 new test cases covering count threshold, size threshold, boundary, and disabled-count scenarios
Problem
The current
DownloadPlanBuilderuses a single threshold: when the combined download size of all chain (delta) packages reaches 80% of the best full package size, it switches to the full package, discarding all chain packages.This 80% threshold has several issues:
Ignores package count. A user with 2 large chain packages close to full size would overpay (e.g., 850 MB chain vs 1 GB full — user pays +150 MB for no reason). Conversely, 20 small chain packages well below the size threshold would still apply — creating 20 points of failure.
Runtime fallback already exists. Each chain package is already paired with a pre-downloaded
FallbackFull. If a chain patch fails at runtime, the system automatically falls back to the full package. An overly eager download-stage switch is unnecessary.Absolute overpay can be huge. 20% of a 2 GB full package is 400 MB — a significant extra download for users on metered/slow connections.
Solution
Replace with a count-first heuristic:
MaxChainBeforeFallback(default 8)This prioritizes reliability (fewer packages = fewer failure points) while the size comparison acts as a hard guardrail (never download more than necessary).
MaxChainBeforeFallbackis configurable viaUpdateConfiguration— set to 0 to disable count-based fallback entirely.Changes
UpdateConfiguration: addMaxChainBeforeFallback(default 8)DownloadPlanBuilder.Build(): new count-first + size guardrail logicClientStrategy: plumbMaxChainBeforeFallbackthrough