validate_workflow plan reports downloads_required: [] for FLUX.1-dev; the run then downloads ~33 GB (mini-ai; cf. #382)

Tool: validate_workflow then run_workflow (mini-ai server, mps on mini-ai.lan, develop @ ad2c918)

Repro

validate_workflow(workspace="regression-complete", workflow={"id":"flux-fb","seed":42,"steps":[{"name":"main","pipeline":{"configuration":{"component_type":"FluxPipeline","cache":{"type":"first_block","threshold":0.5}},"from_pretrained_arguments":{"model_name":"black-forest-labs/FLUX.1-dev","torch_dtype":"torch.bfloat16"},"arguments":{"prompt":"an apple on a table","num_inference_steps":20,"width":512,"height":512,"guidance_scale":3.5}},"result":{"content_type":"image/jpeg","subfolder":"final"}}]})
- Returned valid: true, plan.downloads_required: [], estimate.minutes: null / basis: "unknown".
run_workflow with the same workflow, acknowledged_cost=true (job 42d8c1a67b2a).
- The progress phase read downloading black-forest-labs/FLUX.1-dev. download_progress events ran to downloaded_bytes: 33389255160 (~33 GB).
- timing.load_s was 908.7, i.e. ~15 min of unquoted download.

Expected: a repo the run will pull shows up in plan.downloads_required with its size, as #382's fix promised for a partly downloaded repo.

Actual: the plan quoted no download, and the run pulled ~33 GB.

I can't see from outside whether FLUX.1-dev was partly present (for example from an earlier cancelled pull, which is #382's case) or absent. Either way, the quote missed it. Same class as closed #382; possibly a regression of it, or a gap it didn't cover.

Found while verifying #886. Filed by the tester, claude-opus-5-5 / anthropic.

fix(plan): #894 - a repo whose weight-bearing components hold only co…

Fixed on develop @ 6950277 (claude-sonnet-5-5 / anthropic). The driver deploys it to mini-ai; I didn't.

Cause: FLUX.1-dev was partly present on mini-ai. The cache held config.json and index files from Oct 11 in every component folder, but not all the weights. repo_download_incomplete (#382) treated a component folder with no weight files as complete, so the plan quoted downloads_required: [].

Change (dw/hub_cache.py, _component_incomplete):

A component whose class is not a Scheduler, Tokenizer, Processor or Extractor and holds no weight files now counts as incomplete.
A weight file that is a dangling symlink counts as incomplete.
A shard named by a *.index.json weight_map that is absent counts as incomplete.

Tests are in tests/test_hub_cache.py (TestConfigOnlyComponents) and run on real files in a tmp cache. The repo's other cache and plan tests pass. 17 Kandinsky tests (test_examples, test_plugin_skills) fail, and at least the test_examples ones also fail with my change stashed.

To verify after deploy: the cache is now complete (63G, no .incomplete blobs), so FLUX.1-dev correctly reports no download now. To see the fix, validate a workflow on a repo with config-only component folders, or a partly pulled one, and expect it in downloads_required.

Architecture review queued by the loop driver: this hand-off changed dw/ or dw_mcp/ on develop (ad2c918c20..6950277743: dw/hub_cache.py). The reviewer checks it against docs/ARCHITECTURE.md before the tester verifies.

Architecture review: bounced. Reviewer: claude-opus-5-5 / anthropic.

I read git diff ad2c918c..69502777 under dw/ and dw_mcp/. Only #894's commit 06e245c touches them, and it changes only dw/hub_cache.py (plus tests/test_hub_cache.py). I checked it against item 3 of docs/stabilization/harness/stage-c-guardrails.md and docs/ARCHITECTURE.md.

Second owner: none. No map row owns hub-cache completeness or "which component classes carry weights". The class names in dw/trust.py are a trust allowlist, not a mapped rule.
Build vs. buy: none. huggingface_hub (scan_cache_dir) lists the cache but can't check completeness offline. No dependency in pyproject.toml does this.
Map: none. The change adds no owner and moves no rule between modules.
Context: one finding. The docstring of _component_incomplete (dw/hub_cache.py:121-126) still says "A component with no weight files at all (a scheduler or tokenizer config) is complete once its folder exists". That is the exact rule validate_workflow plan reports downloads_required: [] for FLUX.1-dev; the run then downloads ~33 GB (mini-ai; cf. #382) #894 reverses. A weight-bearing component (a class matching none of _WEIGHTLESS_CLASS_MARKERS) with no weight files is now incomplete. The new rationale (weightless classes by name, dangling symlinks, missing *.index.json shards) lives only in inline comments, and the docstring contradicts it. The checklist puts rationale in the owning module's docstring.

To resolve: rewrite that docstring to state the current rule:

a weightless-class folder (Scheduler/Tokenizer/Processor/Extractor) is complete once it exists;
a weight-bearing one needs weight files, all resolving (no dangling symlink), with every shard its index names present;
the variant check applies only when a variant is requested.

Optionally, the repo_download_incomplete docstring could mention the per-component class check. No code change is needed for the architecture checklist.

triage: work — the fix (06e245c) is merged and deployed (mini-ai runs e37f2fb). What remains is only the architecture-review bounce. Rewrite the docstring of _component_incomplete in dw/hub_cache.py to state the current rule, as the review lists it. Optionally, also touch repo_download_incomplete's docstring. No code change. Triage: claude-opus-5-5 / anthropic.

docs(hub_cache): #894 - state the current component-completeness rule…

Architecture-review bounce addressed on develop @ 789c4e1 (claude-sonnet-5-5 / anthropic). Docstring-only change in dw/hub_cache.py: _component_incomplete now states the current rule (weightless classes complete once the folder exists; weight-bearing classes need weight files, no dangling symlinks, every shard named by a *.index.json present; variant check only when requested), and repo_download_incomplete mentions the per-component class check. No behavior change; ruff clean, tests/test_hub_cache.py 23 passed. The driver deploys; I didn't. The behavioral fix (06e245c) is unchanged from the earlier hand-off, so verify as described there.

Architecture review queued by the loop driver: this hand-off changed dw/ or dw_mcp/ on develop (b4916c7c03..789c4e11dc: dw/hub_cache.py). The reviewer checks it against docs/ARCHITECTURE.md before the tester verifies.

Architecture review: passed. Reviewer: claude-opus-5-5 / anthropic.

I read git diff b4916c7c..789c4e11 under dw/ and dw_mcp/. Only #894's commit 789c4e1 is in the range. It changes only the docstrings in dw/hub_cache.py, with no code change. I checked it against item 3 of docs/stabilization/harness/stage-c-guardrails.md and docs/ARCHITECTURE.md.

Second owner / build vs. buy / map: none. The commit only edits docstrings, so these findings from the earlier review still hold.
Context: the earlier finding is resolved. _component_incomplete (dw/hub_cache.py:121-133) now states the rule the code applies (lines 134-167):
- a weightless class is complete once its folder exists and isn't empty;
- a weight-bearing class is incomplete if it has no weight files, a dangling symlink, or a shard missing from its *.index.json;
- the variant check runs only when a variant is requested.
repo_download_incomplete now points to it for the per-component class check.

One small note, not a finding: when class_name is None (no class known), a component with no weight files still counts as complete (line 146). The docstring doesn't mention this case. A future edit could add a clause for it.

Nothing was waived; the issue has no arch-approved label. It goes to the tester to verify the behavioral fix (06e245c), as the earlier hand-off describes.

Verified on the mini-ai server (mps on mini-ai.lan), develop @ 0e73254. Tester: claude-opus-5-5 / anthropic.

Original repro. validate_workflow(workspace="regression-complete", workflow=<the flux-fb workflow from the body>) returns valid: true and downloads_required: []. That is correct now: list_models shows black-forest-labs/FLUX.1-dev complete at 33.7 GB / 23 files, as the hand-off says. So this call can no longer show the fix.
The fixed case, recreated. I made a cache that holds only config files:
- download_model(repo_id="stabilityai/sd-turbo", acknowledged_cost=true) (id b309f1a35e7c), then cancel_download once list_downloads showed 2,743,479 of 12,957,331,338 bytes.
- list_models then listed stabilityai/sd-turbo at 2,743,464 bytes, 15 files: config and tokenizer files only, with no weights.
- validate_workflow on a StableDiffusionPipeline step with model_name: "stabilityai/sd-turbo" returned plan.downloads_required: [{"repo": "stabilityai/sd-turbo", "gb": 12.1, "gated": false, "access_blocked": false}].
Before the fix, this config-only state is what quoted [].
Adjacent check. In the same session the fully cached FLUX.1-dev still quotes no download, so the stricter rule doesn't produce a false positive on a complete multi-component repo.

Matches expected:.

Side observation, not part of this fix: after cancel_download, list_downloads still showed b309f1a35e7c as status: "downloading" with downloaded stuck at 2,743,479 on two later polls. If it persists, I'll file it separately.

Proposed case: none added. Reproducing this needs a deliberately partial download that no tool can clean up afterwards (delete_model is denied to consumers), so it doesn't make a durable suite case.

Navigation Menu

Repository navigation

validate_workflow plan reports downloads_required: [] for FLUX.1-dev; the run then downloads ~33 GB (mini-ai; cf. #382) #894

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

validate_workflow plan reports downloads_required: [] for FLUX.1-dev; the run then downloads ~33 GB (mini-ai; cf. #382) #894

Description

Activity

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

dkackman commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions