jdx/mise · error

unsupported task cache archive entry type

Error message

unsupported task cache archive entry type

What it means

While converting a downloaded task-cache archive into the content-addressable store (CAS), archive_to_cas walks each archive entry and maps it to an ArchiveNode (file, directory, or symlink). If an entry's type is none of these (e.g. hardlink, fifo, device node, or other exotic tar entry kinds), it cannot be represented, so mise bails. This guards the CAS from storing entries it cannot later restore faithfully.

Solutions

  1. Repackage the cache archive so it contains only regular files, directories, and symlinks (e.g. tar without --hard-dereference, no device/fifo entries).
  2. Identify which entry has the unsupported type (inspect with `tar -tvf archive.tar`) and remove or convert it.
  3. Regenerate the cache by re-running the task so mise builds the archive itself from real filesystem contents.
  4. If the producer legitimately needs hardlinks, switch it to emit regular files or symlinks instead.

Example fix

// before: producer emits hardlinks
tar -cf cache.tar --hard-dereference=no dir
// after: dereference everything into plain files
tar -cf cache.tar --hard-dereference dir
Defensive patterns

Strategy: validation

Validate before calling

const OK = new Set(['file', 'dir', 'symlink']);
const bad = entries.filter(e => !OK.has(e.type));
if (bad.length) throw new Error(`unsupported entry types: ${bad.map(e => e.path)}`);

Type guard

const isSupportedEntry = (e) => ['file','dir','symlink'].includes(e.type);

Prevention

When it happens

Trigger: Restoring/committing a remote task cache archive produced by a tool that emitted entry kinds other than regular files, directories, and symlinks — e.g. tar archives containing hardlinks, block/char devices, or FIFOs.

Common situations: A custom or third-party cache-packaging step created the archive with unusual entry types; a cache archive was hand-crafted or generated on a platform that records device nodes; archives tampered with or corrupted in transit.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/d3a32fe7a00333ce. Report an issue: GitHub.

Appendix: source

Thrown at src/task/task_cache_store.rs:610

                digest: CacheDigest {
                    algorithm: "blake3".into(),
                    hash: hasher.finalize().to_hex().to_string(),
                    size,
                },
                executable: mode & 0o111 != 0,
                mode,
                file: temporary,
            }
        } else if entry_type == EntryType::Symlink {
            let target = entry
                .header()
                .link_name()
                .ok_or_else(|| eyre!("remote cache symlink is missing its target"))?
                .into_owned();
            validate_cache_symlink_target(&entry_path, &target)?;
            ArchiveNode::Symlink { mode, target }
        } else {
            bail!("unsupported task cache archive entry type");
        };
        if nodes.insert(entry_path.clone(), node).is_some() {
            bail!("task cache archive contains duplicate paths");
        }
        let mut parent = entry_path.parent();
        while let Some(path) = parent {
            nodes
                .entry(path.to_path_buf())
                .or_insert(ArchiveNode::Directory { mode: 0o755 });
            parent = path.parent();
        }
    }

    fn build_directory(
        path: &Path,
        nodes: &BTreeMap<PathBuf, ArchiveNode>,
        directory_uploads: &mut Vec<BlobUpload>,
    ) -> Result<CacheDigest> {

View on GitHub (pinned to 533346cc37)