download-cache

Implements content-addressed download caching with hash verification, retries, and parallel queues in Rust.

Updated Sep 8, 2026
One-click install
npx skills add https://github.com/Sixdd6/grid-craft-launcher --skill download-cache-sixdd6
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: download-cache
Source: https://github.com/Sixdd6/grid-craft-launcher/tree/main/.claude/skills/download-cache
Command: npx skills add https://github.com/Sixdd6/grid-craft-launcher --skill download-cache-sixdd6

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When working on the gcl-core download and HTTP modules of this Minecraft launcher, you need to understand how files are fetched, verified, cached, and deduplicated so you do not break invariants like streaming caps, hash checks, or redirect guards. ## Core Features & Use Cases - Content-addressed cache: Every download lands in cache/objects/<sha1> and is hard-linked to its final path, so Modrinth and CurseForge copies of the same jar are stored once. - Verified streaming downloads: SHA-1 and size are checked while streaming, partial files use unique .part staging names, and mismatches trigger bounded retries before a hard error. - Media caches with security policies: Icon and description-image caches enforce HTTPS-only schemes, host allowlists, private-IP refusal, redirect re-validation, byte caps, and LRU-style pruning. - Use Case: Before modifying gcl-core/src/download/ or http/, load this Skill to learn why downloads must stream (never buffer whole files), why retries skip 404/403, and how the redirect guard re-checks the allowlist on every hop. ## Quick Start Ask the assistant to explain or modify the download queue, cache, or icon fetching logic in gcl-core using the download-cache conventions.

Frequently Asked Questions about download-cache

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How does the gcl-core download cache verify file integrity?▼

Each download computes SHA-1 while streaming and compares it to the expected hash; a mismatch deletes the file and retries, and a third mismatch returns Error::HashMismatch. When no hash is known, the size is checked instead.

How are duplicate files from Modrinth and CurseForge deduplicated?▼

The cache key is the file's SHA-1, so if either source serves the same jar, the second download links the existing object in cache/objects. CurseForge files without SHA-1 are hashed after download and stored under their computed hash.

Why are icon downloads restricted to certain hosts?▼

IconCache only allows HTTPS URLs on cdn.modrinth.com, media.forgecdn.net, and edge.forgecdn.net, refusing others with Error::DisallowedHost. The check runs before the request and again on every redirect hop to prevent allowlist bypass.

What HTTP errors are retried by the download client?▼

The client retries connect errors, 5xx responses, and 429 rate limits up to 3 attempts with 500 ms, 2 s, and 8 s backoff, honoring Retry-After and Modrinth rate-limit headers. It never retries 404 or 403 responses.

How are the icon and image caches pruned?▼

MediaCache::prune sorts cache files by modification time and deletes the oldest until the directory is under its cap: 64 MiB for icons and 256 MiB for images. Launcher::open runs one background sweep per start, and gcl config prune-cache triggers it manually.

What are the rules for writing new download code in gcl-core?▼

Stream files instead of holding them in memory, never download inside spawn_blocking (only hash or unzip there), and do not retry 404 or 403. Stage writes in unique .part files and rename on success so concurrent downloads never collide.