main
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 marreiradigital
|
66f7ef8cfe |
fix(download): reentra no acelerador na proxima tentativa apos queda
Achados do CodeRabbit no PR #1942. O mais grave: com o erro classificado como transitorio, o codigo mantinha o acelerador ligado mas caia direto no `snapshot_download` na MESMA tentativa. Se esse download desse certo, o laco terminava e o manifesto do `.part` nunca era reusado — exatamente o recomeco-do-zero que a correcao existe para impedir. Agora o erro transitorio e propagado para o retry externo, cuja proxima tentativa reentra no `_segmented_snapshot` e retoma do manifesto. A decisao virou o helper puro `_segmented_retry_plan`, testavel direto (o laco mora dentro de `install_model`, uma rota de ~200 linhas). A ultima tentativa fica reservada para o caminho simples, entao o acelerador continua sem poder ser o motivo de um install falhar de vez. Tambem deste round de revisao: - `Invoke-CimMethod ... Terminate` tinha o retorno descartado com `$null =`. O Win32_Process.Terminate reporta falha pelo ReturnValue, nao lancando: um kill negado por permissao era reportado como sucesso e a porta seguia presa. Agora o ReturnValue e validado, com exit 4 proprio e a mensagem carregando o codigo. - O teste de concorrencia era vazio: o handler sincrono do MockTransport retorna antes de qualquer outra task rodar, entao `peak` nunca passava de 1 e a asserção `peak <= 4` passava sem exercitar o semaforo. Passou a segurar as requisicoes abertas com um asyncio.Event e a exigir `peak == 4` (verificado: com o semaforo afrouxado para 1000, o teste acusa 31). - A doc dizia que OMNIVOICE_DOWNLOAD_MAX_WORKERS limita as faixas e que origem sem Range cai no snapshot_download. Nenhum dos dois: `_segmented_snapshot` nao passa `num_connections` (usa as 8 padrao) e origem sem Range vira stream unico dentro do proprio acelerador. - Entradas de Highlights do CHANGELOG sem o `(#NNNN)` exigido. |
||
|
marreiradigital
|
0d3fb07c1f |
fix(download): segmenta em blocos limitados e retoma o acelerador
O downloader segmentado gravava progresso no manifesto apenas quando um segmento INTEIRO terminava, e dimensionava os segmentos como tamanho/num_connections. Num blob de 806 MB isso dava 8 segmentos de ~100 MB: numa conexão que cai a cada ~50 MB nenhum segmento jamais completava, o manifesto nunca era escrito e cada tentativa recomeçava do zero. Pior, o acelerador só rodava na PRIMEIRA tentativa (`_attempt == 1`), então depois da primeira queda todas as retentativas iam para o `snapshot_download` e o `.part` acumulado ficava órfão para sempre. Agora os segmentos são limitados a 16 MB e a concorrência passa a ser controlada por semáforo (antes vinha da própria contagem de segmentos), e o acelerador é preservado entre tentativas quando o erro é de rede — reusando `_is_retryable_download_error`, que já é a fonte única dessa classificação. Ele só é desligado de vez quando a falha NÃO é transitória, ou seja, quando o acelerador de fato não serve naquele host. Reproduzido em rede real: `peer closed connection without sending complete message body (received 54260979, expected 100708200)`. |
||
|
|
4cc55ab852 |
Fast model downloads: Xet fast path + accurate progress (FDL W0–W2 + W4) (#424)
* feat(downloads): Xet fast path + accurate progress (FDL W0–W2)
Make model downloads fast and show accurate downloaded/remaining/speed.
Research confirmed hf-xet already implements the IDM/uGet technique
(content-defined chunking, parallel byte-range gets, dedup, resume), and
the spike found all 25 catalog repos are Xet-backed — so the win is
driving Xet well + accurate progress, not a custom downloader.
W1 — maximize + guarantee Xet:
- pin huggingface_hub>=1.7 + hf-xet>=1.1 (was transitive); no hf_transfer
- drive snapshot_download with explicit tqdm_class + max_workers + endpoint
- opt-in HF_XET_HIGH_PERFORMANCE / HDD sequential-write knobs (default off)
- /system/info reports fast_download {xet_enabled, xet_version, high_perf}
W2 — accurate progress:
- dry_run preflight -> install_plan event (exact total/cached/remaining)
- utils/download_aggregator.py: one overall bar; byte bars (by id) vs the
"Fetching N files" count bar; windowed rate; emits one 'aggregate' event
- frontend overall bar (speed/remaining/ETA), cached-skip, ⚡ fast badge
Known limit (verified live): under Xet+hf_hub 1.7.2 per-file byte bars
never advance/close via tqdm, so mid-download the bar is file-granular and
bytes flush to the exact total on completion. Classic-LFS/mirror repos get
true byte progress (W4).
Drive-by: download.py used os.walk without importing os (latent NameError
in _validate_snapshot_has_weights on every install) — fixed.
Tests: tests/backend/setup/test_download_preflight.py (10). Spike + plan
under .planning/quick/260613-fdl-fast-model-downloads/.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(downloads): opt-in mirror + cancel + docs (FDL W4)
- mirror (FDL-10): snapshot_download(endpoint=) honours prefs hf_endpoint /
env HF_ENDPOINT on preflight + download (per-call, no process-wide env).
Documented as the classic-LFS path (no Xet) for restricted networks.
- cancel (FDL-11): POST /models/install/cancel {repo_id} stops further
retries at the next boundary, emits install_cancelled, clears the cooldown
(cancel is intent, not failure). Frontend treats it as a terminator.
- docs (FDL-12): docs/downloading-models.md (Xet fast path, progress
semantics + byte-speed limitation, opt-in tuning, mirror, cancel,
troubleshooting) + README pointer. Docs-sync rule satisfied.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(planning): model-management v2 cleanup plan (mm2)
GSD plan for cleaning the model-management subsystem: registry unload-on-
switch + per-engine unload() (fixes VRAM leak), model_lifecycle facade,
unified idle/timeout config, bounded cooldowns, sidecar VRAM self-report,
cache-fallback logging. Planning artifact only — no code.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(downloads): reconcile with main's HF_HUB_DISABLE_XET; honest status
Rebasing onto main surfaced that main forces HF_HUB_DISABLE_XET=1 (classic
LFS) because Xet progress bypasses the tqdm hook — the same limitation found
here. Reconcile instead of fight:
- /system/info fast_download now reports runtime truth: xet_installed +
xet_active (installed AND not HF_HUB_DISABLE_XET) + xet_enabled alias. The
⚡ badge only shows when Xet actually runs; startup log says
"downloads: Xet disabled → legacy LFS".
- complete(): clear the rate window before the final flush so crediting the
full size in one step can't emit an absurd instantaneous rate.
- docs/downloading-models.md rewritten: default is legacy LFS for accurate
progress; Xet is opt-in via HF_HUB_DISABLE_XET=0. hf-xet pin stays (ready
for a future Xet progress hook).
W2 (preflight total/remaining + aggregate bar + exact completion) is the
value on either path; W1's "maximize Xet" is dormant by main's design.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat(downloads): opt-in segmented multi-connection accelerator (FDL W3)
Since main forces Xet off (HF_HUB_DISABLE_XET=1), the default path is
single-stream legacy LFS — so a segmented downloader is the way to get BOTH
parallel speed and live byte progress.
- services/segmented_download.py: async multi-connection Range downloader for
one file — parallel byte-ranges, resume (.part + manifest), per-segment
short-read truncation guard, optional sha256/etag verify, cancel, and a
single-stream fallback when the server won't range. Auth-safe: the HF
Authorization header is sent only to huggingface.co/hf.co and never
forwarded to a CDN host on redirect (unit-tested).
- dispatch (download.py): opt-in via prefs segmented_downloader / env
OMNIVOICE_SEGMENTED_DOWNLOAD (default off). When on and Xet inactive,
fetches each file into the HF cache mirroring hf_hub_download (blobs +
snapshot symlinks + refs/main), feeding real bytes to the aggregator. Any
failure falls back to snapshot_download — never breaks a correct install.
- fix: complete() was adding a full total on top of accumulated segmented
bytes (2x); now replaces byte bars so the sum is exactly total.
Verified live (accelerator on): real byte progress to ~16.6 MB/s, final
bytes==total, /models installed=True, delete frees correctly.
Tests: test_segmented_download.py (7) + aggregator double-count regression.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test(downloads): relocate FDL tests to top-level; loop-isolate segmented test
CI runs the full suite, which exposed a pre-existing test-isolation leak:
several tests/backend/** fixtures purge core.*/services.* from sys.modules
under a temp OMNIVOICE_DATA_DIR and never restore, leaving core.config/core.db
bound to a dead temp dir. It only bites when collection order puts a purging
test ahead of a real-DB reader (test_longform_jobs). Adding tests under
tests/backend/setup/ reordered collection and tripped it.
Fix without touching the shared (fragile) fixtures or risking class-identity
breakage from a blanket sys.modules restore:
- move the two FDL test files to top-level tests/ (tests/test_fdl_*.py) so
tests/backend/** collection order is identical to main — longform passes.
- rewrite the segmented test to run each case under asyncio.run() (fresh loop)
instead of asyncio.get_event_loop(), which an earlier async test can leave
closed in the full suite.
Full suite green locally: 1364 passed, 0 failed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: mergetest <test@local>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|