bugfix: wasmtime: instantiating function type incompatibility

[akorchyn]

Resolves: #12062

This PR resolves the issue with the wasmtime function type incompatibility.
To understand the issue, I highly recommend my investigation comments on the issue itself: #12062

To be honest, I'm not sure it's a proper fix as I guess the root cause of the issue is somewhere outside of the file that leads to running under different engines/settings, leading to instantiating failures. It's a bit weird that the WasmtimeVM instance and Module instance could be different somehow as wasmtime::Engine is an arc wrapper. And module seems to clone it inside which should be still the same instance.

I could reproduce the issue only by tweaking the code manually by recreating an engine before the linking. It means that something more complex happens and we need a test on that

But this fix resolves an issue reported by #12062: https://github.com/near/near-workspaces-rs/actions/runs/10835958697/job/30200440749

CC @race-of-sloths

[race-of-sloths]

@akorchyn Thank you for your contribution! Your pull request is now a part of the Race of Sloths!
Weekly streak is on the road, smart strategy! Secure your streak with another PR!

Current status: executed

Reviewer	Score
@frol	8

Your contribution is much appreciated with a final score of 8!
You have received 163 (80 base + 35 weekly bonus + 40 monthly bonus + 5% lifetime bonus) Sloth points for this contribution

Congratulations @akorchyn! Your PR was highly scored and you completed another monthly streak! To keep your monthly streak make another pull request next month and get 8+ score for it

What is the Race of Sloths

Race of Sloths is a friendly competition where you can participate in challenges and compete with other open-source contributors within your normal workflow

For contributors:

• Tag @race-of-sloths inside your pull requests
• Wait for the maintainer to review and score your pull request
• Check out your position in the Leaderboard
• Keep weekly and monthly streaks to reach higher positions
• Boast your contributions with a dynamic picture of your Profile

For maintainers:

• Score pull requests that participate in the Race of Sloths
• Engage contributors with fair scoring and fast responses so they keep their streaks
• Promote the Race to the point where the Race starts promoting you
• Grow the community of your contributors

Feel free to check our website for additional details!

Bot commands

• For contributors
  • Include a PR: @race-of-sloths include to enter the Race with your PR
• For maintainers:
  • Invite contributor @race-of-sloths invite to invite the contributor to participate in a race or include it, if it's already a runner.
  • Assign points: @race-of-sloths score [1/2/3/5/8/13] to award points based on your assessment.
  • Reject this PR: @race-of-sloths exclude to send this PR back to the drawing board.
  • Exclude repo: @race-of-sloths pause to stop bot activity in this repo until @race-of-sloths unpause command is called

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.59%. Comparing base (0e7df47) to head (5f856a4).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12096      +/-   ##
==========================================
- Coverage   71.59%   71.59%   -0.01%     
==========================================
  Files         818      818              
  Lines      164532   164532              
  Branches   164532   164532              
==========================================
- Hits       117794   117789       -5     
- Misses      41595    41604       +9     
+ Partials     5143     5139       -4     

Flag	Coverage Δ
backward-compatibility	0.17% <0.00%> (ø)
db-migration	0.17% <0.00%> (ø)
genesis-check	1.26% <0.00%> (ø)
integration-tests	38.68% <0.00%> (-0.03%)	⬇️
linux	71.19% <100.00%> (-0.01%)	⬇️
linux-nightly	71.11% <100.00%> (-0.01%)	⬇️
macos	54.06% <100.00%> (+0.01%)	⬆️
pytests	1.52% <0.00%> (ø)
sanity-checks	1.33% <0.00%> (ø)
unittests	65.38% <100.00%> (+<0.01%)	⬆️
upgradability	0.21% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[akorchyn]

@akhi3030 can you re-add to the merge queue?

[race-of-sloths]

🥁 Score it!

@frol, please score the PR with @race-of-sloths score [1/2/3/5/8/13]. The contributor deserves it.
If no scoring is provided within 24 hours, this PR will be scored as 2 🦥

[frol]

@race-of-sloths score 8

[nagisa]

The fix seems reasonable. We do indeed have a problem where each individual invocation of the runtime will operate with a brand new Engine, but where we also kind-of need to use the original engine with which a loaded-and-cached module has been created.

It might make a ton of sense to re-use the same engine for everything, but since the engine holds onto things like all the types it has ever seen, that would lead to eventually unbounded memory growth. The reason why we're seeing type mismatches here is exactly because the module instance most likely references types by indices into engine somewhere...

[akorchyn]

Thank you. However, I still feel weird about how these engines differ. As we load from cache with the engine from the State and the Module::deserialize seems to be clone Arc under the hood, so they should be the same (inside the Engine and inside the State), but it's not really true :(
Maybe there is some issue on the library level ...