Stream: git-wasmtime

Topic: wasmtime / issue #14804 Cache worker panics on a valid co...

Wasmtime GitHub notifications bot (Oct 19 2026 at 11:01):

clippytool opened issue #14804:

Test Case

No Wasm module is needed: the panic depends only on the cache configuration.

Steps to Reproduce

1. Create a config file (wasmtime config new prints the default path) containing:

   toml [cache] file-count-soft-limit = "18446744073709551615" files-total-size-soft-limit = "18446744073709551615" file-count-limit-percent-if-deleting = "70%" files-total-size-limit-percent-if-deleting = "70%"

2. Run any module that gets cached, e.g. wasmtime hello.wasm.

3. The first cache update triggers the cleanup task, which panics.

Expected Results

The configuration is accepted (it is), and the cleanup task computes its
deletion thresholds and runs normally.

Actual Results

thread '<unnamed>' panicked at crates/cache/src/worker.rs:484:14:
called `Option::unwrap()` on a `None` value

(:488 is the same expression for the file count.) The panic happens on the
cache worker thread, so the CLI itself keeps running, but the worker is gone for
the rest of the process: stats are no longer updated, recompression and cleanup
never run again, and every subsequent event logs "Failed to send asynchronously
message to worker thread". Builds using panic = "abort" abort the process.

Versions and Environment

Wasmtime 51.0.0-dev, commit a33c18ed39. macOS aarch64 (architecture-independent).

Extra Info

CacheConfig::validate bounds file-count-limit-percent-if-deleting and
files-total-size-limit-percent-if-deleting to 0-100, but nothing bounds
file-count-soft-limit / files-total-size-soft-limit, which are plain u64
values. The cleanup task then computes

let tsl_if_deleting = total_size_limit
    .checked_mul(self.cache_config.files_total_size_limit_percent_if_deleting() as u64)
    .unwrap()
    / 100;

so any soft limit above u64::MAX / 70 (~2.6e17) with 70% panics instead of
producing a threshold. u64::MAX is a legitimate "effectively unlimited"
setting, so I don't think the fix should reject large values in validation;
computing the percentage without overflowing is enough, e.g.

fn percent_of(value: u64, percent: u8) -> u64 {
    let percent = u64::from(percent);
    value / 100 * percent + (value % 100) * percent / 100
}

which equals floor(value * percent / 100) and cannot overflow for percent <= 100.

I reproduced this in a unit test that calls the cleanup task directly with the
configuration above (it panics at the line quoted); I did not run the CLI binary
end-to-end. Happy to send a PR with the fix and the regression test.

Wasmtime GitHub notifications bot (Oct 19 2026 at 22:38):

dicej closed issue #14804:

Test Case

No Wasm module is needed: the panic depends only on the cache configuration.

Steps to Reproduce

1. Create a config file (wasmtime config new prints the default path) containing:

   toml [cache] file-count-soft-limit = "18446744073709551615" files-total-size-soft-limit = "18446744073709551615" file-count-limit-percent-if-deleting = "70%" files-total-size-limit-percent-if-deleting = "70%"

2. Run any module that gets cached, e.g. wasmtime hello.wasm.

3. The first cache update triggers the cleanup task, which panics.

Expected Results

The configuration is accepted (it is), and the cleanup task computes its
deletion thresholds and runs normally.

Actual Results

thread '<unnamed>' panicked at crates/cache/src/worker.rs:484:14:
called `Option::unwrap()` on a `None` value

(:488 is the same expression for the file count.) The panic happens on the
cache worker thread, so the CLI itself keeps running, but the worker is gone for
the rest of the process: stats are no longer updated, recompression and cleanup
never run again, and every subsequent event logs "Failed to send asynchronously
message to worker thread". Builds using panic = "abort" abort the process.

Versions and Environment

Wasmtime 51.0.0-dev, commit a33c18ed39. macOS aarch64 (architecture-independent).

Extra Info

CacheConfig::validate bounds file-count-limit-percent-if-deleting and
files-total-size-limit-percent-if-deleting to 0-100, but nothing bounds
file-count-soft-limit / files-total-size-soft-limit, which are plain u64
values. The cleanup task then computes

let tsl_if_deleting = total_size_limit
    .checked_mul(self.cache_config.files_total_size_limit_percent_if_deleting() as u64)
    .unwrap()
    / 100;

so any soft limit above u64::MAX / 70 (~2.6e17) with 70% panics instead of
producing a threshold. u64::MAX is a legitimate "effectively unlimited"
setting, so I don't think the fix should reject large values in validation;
computing the percentage without overflowing is enough, e.g.

fn percent_of(value: u64, percent: u8) -> u64 {
    let percent = u64::from(percent);
    value / 100 * percent + (value % 100) * percent / 100
}

which equals floor(value * percent / 100) and cannot overflow for percent <= 100.

I reproduced this in a unit test that calls the cleanup task directly with the
configuration above (it panics at the line quoted); I did not run the CLI binary
end-to-end. Happy to send a PR with the fix and the regression test.

Last updated: Oct 31 2026 at 23:03 UTC