Two CodeRabbit findings on PR #9057:

1. `BlobLock::acquire` used `AsRawFd` + `libc::flock` unconditionally,
   which won't compile on non-Unix targets. Wrap the flock-specific
   block in `#[cfg(unix)]`. The non-Unix path still opens the lock
   file (so atomic-rename invariants hold for intra-process callers)
   but skips cross-process locking with a documented caveat —
   dynamo's frontend ships on Linux, this is build-time portability.

2. `reqwest::Client::new()` in async mode has no default timeout. A
   stalled metadata endpoint would hang `download_config()`
   indefinitely. Build the client with explicit
   `connect_timeout(10s)` + total `timeout(300s)`. 5 min covers a
   1 GiB file at slow speeds; realistic metadata files complete in
   seconds.

Refs #8749 #9057

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>

…d skew (gh-8749)

Diagnostic for the trtllm Multi-GPU `raw_embeddings_epd-2` failure on
PR #9057. The frontend errors with "missing eos_token_id in config.json
and generation_config.json, cannot load" because slug_dir lacks
generation_config.json. Two unknowns to surface:

1. **Worker side:** when does `from_repo_checkout` settle on
   `gen_config = None`? `GenerationConfig::from_disk(local_path).ok()`
   silently swallows errors. If the file IS on disk but loading failed,
   that's a real bug — log it as a warning. If the file is genuinely
   absent, log at debug. Either way we get attribution.

2. **Frontend side:** when `resolve_metadata_files` runs, log which
   slots were populated on the MDC at info level. A None gen_config
   slot here means no symlink in slug_dir, which is exactly the
   condition that produces the eos_token_id error downstream.

Both diagnostics ship at info/warn so they'll show up in CI logs without
extra config. Will revert the info-level slot log to debug once the
test failure is understood.

Refs #8749 #9057

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>

…h-8749)

`resolve_metadata_files`'s file:// arm was the frontend mirror of the
canonicalize→file_name anti-pattern that the capstone branch already
fixed for the worker side in `local_model.rs::move_to_self_host`
(commit 262f314). Same shape, different code path:

  - Worker (capstone): synthesizes `http://<worker>/v1/metadata/<slug>/<filename>`,
    used to take filename from canonicalized path → blob hash.
  - Frontend (this PR): synthesizes `file://<canonicalized>` + records
    filename for slug_dir symlink, was taking filename from canonicalized
    path → also blob hash.

Locally reproduced against the actual llava-v1.6-mistral-7b-hf snapshot
at the test's pinned revision 52320fb52229: `download_config` ran to
completion but the slug_dir held entries named for the HF blob hash:

  d84663b8bd0a737e3299f3d2b4be2fe3cd2a0333  (was: generation_config.json)
  8bc605421e7ff49a5f5ab76f2a26fe0de73cf9d3  (was: config.json)
  6f43c1fabc73af13375a3b0c264656711228cd4a  (was: tokenizer.json)
  754adb1891a73bab3f53b94218e6665ec7fc583c  (was: tokenizer_config.json)

Pass 3's `cf.update_dir(&slug_dir)` then rewrote each cf.path to
`<slug_dir>/<logical-filename>` — pointing at nonexistent entries.
Downstream `HFConfig::from_json_file` doing
`file_path.parent().join("generation_config.json")` to fall back to
generation_config.json for `eos_token_id` failed with the test's
"missing eos_token_id" error.

Fix mirrors the capstone: derive the logical filename from cf.path()
BEFORE canonicalize. Canonicalize is still required for
`Url::from_file_path` to accept the path, but its result is used only
for the URL, not for naming.

Regression test: `resolve_metadata_handles_hf_cache_symlinks` builds
an HF-cache-style snapshot (per-file symlinks into a sibling blobs/
layout) and asserts slug_dir has logical filenames, no blob-hex
leakage. Verified locally against the real llava-v1.6 snapshot.

Refs #8749 #9057
Refs capstone fix 262f314

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>

Pass 1 was rewriting cf.path to a `file://<canonicalized>` URL when
the worker's path was a local file. For HF cache snapshots that path
resolves through a symlink into `blobs/<sha>`, so the URL's basename
became the blob hash. Pass 3's `update_dir` then derived the cf's
new path from that basename, leaving cf.path at
`<slug_dir>/<blob-hash>` instead of `<slug_dir>/<filename>` — the
symlinks Pass 2 placed at `<slug_dir>/<filename>` were unreachable
from cf.path, and downstream code reading siblings by name (e.g.
`HFConfig` looking for `generation_config.json` next to
`config.json`) hit "Failed to open file".

Fix mirrors the worker-side fix in `move_to_self_host` from the
capstone: don't mutate cf to a canonicalized URL — construct the
fetch URI as a local string and leave cf.path as the worker
published it. Pass 3's `update_dir` now operates on the original
PathBuf and naturally writes back the logical filename.

Same regression class CodeRabbit caught for the http:// arm, just on
the file:// arm. The existing `download_config_pipelines_local_files
_through_cache` test now uses an HF-cache-style symlink fixture so
this path stays covered.

Refs #8749 #9057

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>

gh-8749)

Pass 1 collapses to one map() call with two helpers. Replaces
`std::fs::canonicalize` with `std::path::absolute` — same effect for
`Url::from_file_path` (needs absolute) without an extra syscall or
symlink-follow. Drops verbose comments that were stating the obvious.

Refs #8749 #9057

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>

…8749)

Worker `move_to_self_host` swaps `fs::canonicalize` for
`std::path::absolute`. Filename derivation is unchanged (still pre-
canonicalize per capstone 262f314). Now both worker and frontend
URL/registry construction follow the same pattern: pre-canonicalize
filename + non-symlink-resolving absolute path.

The http handler's per-request symlink follow is the only behavioral
delta; HF cache blobs are append-only so the resolved path doesn't
go stale.

Refs #8749 #9057

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: nnshah1 <neelays@nvidia.com>