Background
Surfaced during review of #13 (closes #11). Not a bug, an efficiency improvement.
The cost
`rescue_chunked` currently opens a fresh `bootstrap + N` WS connection pool per ChunkedPack bundle, drops them at the end, then opens a new pool for the next bundle. For a repo with K ChunkedPack bundles that's `(N+1) × K` WS connect/disconnect cycles. Local nodes with modest per-client connection caps may see the graceful-degradation `warn!` repeatedly across bundles.
Proposed fix
Hoist the pool out of `rescue_chunked` and pass it down by reference. Open one pool at the top of `rescue()` (or first time we encounter a ChunkedPack), reuse it across all bundles, drop it once at the end. Then `rescue_chunked` takes `pool: &[Arc<Mutex>]` instead of `ws_url: &str`.
The bootstrap connection for the manifest GET could become pool member 0 if we restructure: open the pool once, do the manifest GET on `pool[0]` while holding the lock, release, then dispatch the chunk stream. Saves the dedicated bootstrap connect/disconnect cycle entirely.
Why not in #11
Out of scope. #11 was a focused parallelization that mirrored #7's pattern; reshaping the connection lifecycle is a bigger API change to `rescue` and warrants its own PR.
[AI-assisted - Claude]
Background
Surfaced during review of #13 (closes #11). Not a bug, an efficiency improvement.
The cost
`rescue_chunked` currently opens a fresh `bootstrap + N` WS connection pool per ChunkedPack bundle, drops them at the end, then opens a new pool for the next bundle. For a repo with K ChunkedPack bundles that's `(N+1) × K` WS connect/disconnect cycles. Local nodes with modest per-client connection caps may see the graceful-degradation `warn!` repeatedly across bundles.
Proposed fix
Hoist the pool out of `rescue_chunked` and pass it down by reference. Open one pool at the top of `rescue()` (or first time we encounter a ChunkedPack), reuse it across all bundles, drop it once at the end. Then `rescue_chunked` takes `pool: &[Arc<Mutex>]` instead of `ws_url: &str`.
The bootstrap connection for the manifest GET could become pool member 0 if we restructure: open the pool once, do the manifest GET on `pool[0]` while holding the lock, release, then dispatch the chunk stream. Saves the dedicated bootstrap connect/disconnect cycle entirely.
Why not in #11
Out of scope. #11 was a focused parallelization that mirrored #7's pattern; reshaping the connection lifecycle is a bigger API change to `rescue` and warrants its own PR.
[AI-assisted - Claude]