Skip to content

Wasmtime v42.0.1#2851

Merged
vigoo merged 22 commits intomainfrom
wasmtime-v42.0.1
Mar 4, 2026
Merged

Wasmtime v42.0.1#2851
vigoo merged 22 commits intomainfrom
wasmtime-v42.0.1

Conversation

@vigoo
Copy link
Copy Markdown
Contributor

@vigoo vigoo commented Feb 27, 2026

Resolves #2340

@vigoo vigoo enabled auto-merge (squash) February 27, 2026 15:05
@blacksmith-sh

This comment has been minimized.

@vigoo
Copy link
Copy Markdown
Contributor Author

vigoo commented Mar 4, 2026

In this PR random worker-executor tests were seemingly timing out more frequently than before. I've analysed the logs of these cases, fixed optional tracing support, analysed whole test suite runs with otlp traces, etc and the only conclusion I could get is that it depends on when the test-components are first get compiled - as the compilation itself uses all cores and can be relatively long in debug builds for large components like the TS ones.

I've measured the wasmtime v33 vs v42 compilation performance and checked if they changed anything in their cache implementation but there should not be any regression so my conclusion is that the "more flaky" behavior is just a random coincidence of things running slightly differently with the new engine.

So I've made two changes for worker executor tests (integration tests remain as they are - they test the real behavior where compilation happens when and how it would in production):

  • first, fixed the agent extraction wasmtime config so it uses the same flags as the executor. this way the wasmtime filesystem cache works as intended (it uses these flags in its cache key)
  • latest test-r versions are no longer initializing all test dependencies in a suite, just the ones needed. this made it possible to define the test-components as test dependencies injected to the tests via constructor parameters. The test DSL was changed to accept these PrecompiledComponent objects optionally. When used, the test dependency itself does a "warmup" agent type extraction that fills up both the agent-type cache and wasmtime's own filesystem-based compilation cache

This makes the worker-executor tests much more deterministic because they no longer depend on injecting minutes-long compilations in their execution based on the execution order and parallelism. Everything is pre-initialized for them - while test-r's lazy test-dep evaluation guarantees that we can still run just a subset of the tests without penalties.


/// Creates a `StoreComponentBuilder` from a `PrecompiledComponent`, automatically
/// setting both the WASM file name and the package name.
fn component_dep(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this specific to the worker-executor test dsl? This one doesn't make sense for the integration tests from what I can tell.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking maybe it makes sense for them too (but did not do any such change) to have a central definition of the test components and refer to them with test_dep instead of hardcoding their names everywhere. (The precompilation itself should not happen there, of course)

@vigoo vigoo merged commit 7c299cf into main Mar 4, 2026
27 checks passed
@vigoo vigoo deleted the wasmtime-v42.0.1 branch March 4, 2026 18:43
@github-actions github-actions bot locked and limited conversation to collaborators Mar 4, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Upgrade to wasmtime 39+

2 participants