chore(deps): bump the wasmtime-dependencies group across 1 directory with 3 updates

[dependabot]

Bumps the wasmtime-dependencies group with 3 updates in the / directory: wasmtime, wasmtime-wasi and deterministic-wasi-ctx.

Updates wasmtime from 28.0.1 to 29.0.1

Release notes

Sourced from wasmtime's releases.

v29.0.1

29.0.1

Released 2025-01-21.

Fixed

• Fix a missing increment in WASIp1-to-WASIp2 adapter which affected WASI configurations that have multiple preopened directories. #10064

v29.0.0

29.0.0

Released 2025-01-20.

Added

• Winch now supports epoch-based interruption. #9737

• Pulley, Wasmtime's WebAssembly interpreter, has seen quite a lot of progress and support fleshed out. It's still not 100% complete but should be about ready to start kicking the tires. #9744

• The Wasmtime CLI now supports a -Wextended-const flag to control whether the extended-const wasm proposal is enabled or not. #9768

• Work continues to progress on the AArch64 Winch backend, bringing it closer to completion. #9762 #9767 #9751 #9784 #9781 #9792 #9787 #9798 #9850

• Wasmtime now supports a "custom code publisher" which can be useful when Wasmtime doesn't have built-in support for a particular environment. #9778

• Configuration options have been added for wasmtime-wasi-http outgoing bodies. #9800

... (truncated)

Changelog

Sourced from wasmtime's changelog.

29.0.1

Released 2025-01-21.

Fixed

• Fix a missing increment in WASIp1-to-WASIp2 adapter which affected WASI configurations that have multiple preopened directories. #10064

---

29.0.0

Released 2025-01-20.

Added

• Winch now supports epoch-based interruption. #9737

• Pulley, Wasmtime's WebAssembly interpreter, has seen quite a lot of progress and support fleshed out. It's still not 100% complete but should be about ready to start kicking the tires. #9744

• The Wasmtime CLI now supports a -Wextended-const flag to control whether the extended-const wasm proposal is enabled or not. #9768

• Work continues to progress on the AArch64 Winch backend, bringing it closer to completion. #9762 #9767 #9751 #9784 #9781 #9792 #9787 #9798 #9850

• Wasmtime now supports a "custom code publisher" which can be useful when Wasmtime doesn't have built-in support for a particular environment. #9778

• Configuration options have been added for wasmtime-wasi-http outgoing bodies. #9800

... (truncated)

Commits

• 58282df Release Wasmtime 29.0.1 (#10070)
• e304726 [29.0.x]: Fix a missing increment in p1-to-p2 adapter (#10067)
• 5454077 Release Wasmtime 29.0.0 (#10049)
• c72e60f Fix dropping cached stack with Store::into_data (#10009) (#10014)
• fa6a12d Add release notes for 29.0.0 (#9955)
• 6b615ff Refactor release builds, add aarch64-musl (#9885) (#9934)
• 2bd01ce winch: Standardize method naming convention accross the assemblers (#9918)
• b93e1bc winch: Gracefully handle compilation errors (#9851)
• 5ca3715 feat: Implement simd_f64x2_arith for pulley (#9917)
• f2ab725 Reword LinearMemory and MemoryCreator note about being a new API (#9916)
• Additional commits viewable in compare view

Updates wasmtime-wasi from 28.0.1 to 29.0.1

Release notes

Sourced from wasmtime-wasi's releases.

v29.0.1

29.0.1

Released 2025-01-21.

Fixed

• Fix a missing increment in WASIp1-to-WASIp2 adapter which affected WASI configurations that have multiple preopened directories. #10064

v29.0.0

29.0.0

Released 2025-01-20.

Added

• Winch now supports epoch-based interruption. #9737

• Pulley, Wasmtime's WebAssembly interpreter, has seen quite a lot of progress and support fleshed out. It's still not 100% complete but should be about ready to start kicking the tires. #9744

• The Wasmtime CLI now supports a -Wextended-const flag to control whether the extended-const wasm proposal is enabled or not. #9768

• Work continues to progress on the AArch64 Winch backend, bringing it closer to completion. #9762 #9767 #9751 #9784 #9781 #9792 #9787 #9798 #9850

• Wasmtime now supports a "custom code publisher" which can be useful when Wasmtime doesn't have built-in support for a particular environment. #9778

• Configuration options have been added for wasmtime-wasi-http outgoing bodies. #9800

... (truncated)

Changelog

Sourced from wasmtime-wasi's changelog.

29.0.1

Released 2025-01-21.

Fixed

• Fix a missing increment in WASIp1-to-WASIp2 adapter which affected WASI configurations that have multiple preopened directories. #10064

---

29.0.0

Released 2025-01-20.

Added

• Winch now supports epoch-based interruption. #9737

• Pulley, Wasmtime's WebAssembly interpreter, has seen quite a lot of progress and support fleshed out. It's still not 100% complete but should be about ready to start kicking the tires. #9744

• The Wasmtime CLI now supports a -Wextended-const flag to control whether the extended-const wasm proposal is enabled or not. #9768

• Work continues to progress on the AArch64 Winch backend, bringing it closer to completion. #9762 #9767 #9751 #9784 #9781 #9792 #9787 #9798 #9850

• Wasmtime now supports a "custom code publisher" which can be useful when Wasmtime doesn't have built-in support for a particular environment. #9778

• Configuration options have been added for wasmtime-wasi-http outgoing bodies. #9800

... (truncated)

Commits

• 58282df Release Wasmtime 29.0.1 (#10070)
• e304726 [29.0.x]: Fix a missing increment in p1-to-p2 adapter (#10067)
• 5454077 Release Wasmtime 29.0.0 (#10049)
• c72e60f Fix dropping cached stack with Store::into_data (#10009) (#10014)
• fa6a12d Add release notes for 29.0.0 (#9955)
• 6b615ff Refactor release builds, add aarch64-musl (#9885) (#9934)
• 2bd01ce winch: Standardize method naming convention accross the assemblers (#9918)
• b93e1bc winch: Gracefully handle compilation errors (#9851)
• 5ca3715 feat: Implement simd_f64x2_arith for pulley (#9917)
• f2ab725 Reword LinearMemory and MemoryCreator note about being a new API (#9916)
• Additional commits viewable in compare view

Updates deterministic-wasi-ctx from 0.1.31 to 0.1.34

Release notes

Sourced from deterministic-wasi-ctx's releases.

v0.1.34

What's Changed

• Use wasmtime v31 by @​saulecabrera in Shopify/deterministic-wasi-ctx#88

Full Changelog: Shopify/deterministic-wasi-ctx@v0.1.33...v0.1.34

v0.1.33

What's Changed

• Remove unnecessary wasmtime features by @​jeffcharles in Shopify/deterministic-wasi-ctx#86
• v0.1.33 by @​jeffcharles in Shopify/deterministic-wasi-ctx#87

Full Changelog: Shopify/deterministic-wasi-ctx@v0.1.32...v0.1.33

v0.1.32

What's Changed

• Add a function for replace WASI preview 0 scheduling functions by @​jeffcharles in Shopify/deterministic-wasi-ctx#84
• v0.1.32 by @​jeffcharles in Shopify/deterministic-wasi-ctx#85

Full Changelog: Shopify/deterministic-wasi-ctx@v0.1.31...v0.1.32

Commits

• cb763b9 Merge pull request #88 from Shopify/wasmtime-31
• ab283d1 Use wasmtime v31
• b5c1276 v0.1.33 (#87)
• ab609a6 Remove unnecessary wasmtime features (#86)
• c4e55e7 v0.1.32 (#85)
• 5de63f3 Add a function for replace WASI preview 0 scheduling functions (#84)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[mssalemi]

My Investigation:

How do we use assert_fs?

assert_fs is used in our integration tests for creating temporary files and directories during testing. We used for:

1. Creating temporary input files for tests (temp_input)
2. Creating temporary directories
3. Verifying file existence
4. Writing test content to files using the write_str()

We use it to test outputs, file handling and commands.

Why are we seeing test failures?

The test failures occur due to a dependency version conflict between wasmtime versions:

1. Our project directly depends on wasmtime 28.0.1
2. When upgrading to assert_fs 1.1.3, the build fails with multiple conflicting wasmtime versions in the dependency tree
3. This creates a compiler error in engine.rs where:

   deterministic_wasi_ctx::replace_scheduling_functions(&mut linker)?;

   fails because it expects a Linker<_> from wasmtime version 28.0.1 but receives a Linker<FunctionContext> from a different wasmtime version

The error mentions: "perhaps two different versions of crate wasmtime are being used?"

What changes in assert_fs caused this?

The changes dont seem to apply to use, Claude helped me analysze the changes and in assert_fs 1.1.3 -> upgrading the tempfile dependency from 3.0 to 3.8, which led to the following:

1. New TempDir creation methods were added:

   • new_in()
   • with_prefix()
   • with_prefix_in()

2. This dependency upgrade causes a different build that I believe leads to a conflict with different wasmtime versions in the dependency tree

While the exact dependency path isn't obvious from looking at the public repositories, the compiler error clearly shows wasmtime version conflicts introduced when upgrading to assert_fs 1.1.3.

Potential Solutions

We have two main options to resolve this issue:

Option 1: Stay on assert_fs 1.1.2

• Pin assert_fs to version 1.1.2 in Cargo.toml
• This avoids the dependency conflicts with minimal changes

Option 2: wait for upgrade on wasmtime dependencies (Recommended)

• Upgrade all wasmtime-related dependencies to compatible versions
• This should resolve the version conflict and allow using assert_fs 1.1.3
• dependabot PR (chore(deps): bump the wasmtime-dependencies group across 1 directory with 3 updates #457) that handles this upgrade:

Option 2 seems better in that we can keep this crate up to date.

Recommended Action Plan:

1. Hold this PR (chore(deps): bump assert_fs from 1.1.2 to 1.1.3 #467), wait for wasmtime dependencies PR (chore(deps): bump the wasmtime-dependencies group across 1 directory with 3 updates #457) first
2. After that's merged, rebase this PR and should fix the test issues.

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.