Function delete_cached 

pub async fn delete_cached(
    __arg0: State<AppState>,
    __arg1: Path<String>,
) -> Result<Json<CacheDeleteResponse>, ApiError>

DELETE /api/v1/cache/:key - Invalidate every cache entry for the source file a request cache_key names (issues #3636, #5750).

key is the same cache_key get_cached takes, resolved by the same resolve_request_cache_key. One source file fans out into several cache entries (request, JSON, Parquet geometry, Parquet metadata, symbolic sidecar, crossed with opening-filter and tessellation-quality variants); this removes all of them, not only the variant the key names, because they are all derived from the one file and a client invalidating it cannot know which variants other callers warmed. Any content blob none of them (or any unrelated entry) references any more is reclaimed.

Idempotent: deleting a key with no matching entries is a 200 with deleted: 0, not a 404, so a client can call this unconditionally and retry safely without checking existence first.

Two bounds stand in front of that work, because it is expensive and, in the shipped default configuration (config.api_token unset, so middleware::auth is a pass-through), reachable by anyone:

• the path segment must resolve. remove_by_key_prefix walks the whole cache index twice whatever it is handed, and a miss costs exactly as much as a hit, so without this an arbitrary string buys a full index walk (#4582).
• one such walk runs at a time, enforced by DiskCache itself so the permit travels with the blocking work rather than with this request future (a client that hangs up mid-walk must not release the bound while the walk runs on). A concurrent one is shed with 503 + Retry-After rather than queued; this route is retry-safe by construction.