alexcrichton opened issue #11227:
After https://github.com/bytecodealliance/wasmtime/pull/11127 the
{Typed,}Func::call_asyncentrypoints have a nontrivially-different implementation depending on whether thecomponent-model-asyncfeature is enabled or not. This means that the non-cm-async feature is no longer tested in CI. Ideally we should resolve this situation one way or another.
alexcrichton added the wasm-proposal:component-model-async label to Issue #11227.
shashi1687 commented on issue #11227:
Hi everyone :wave: —I’d love to pick this up.
Quick plan (kept tiny on purpose):
Add a CI lane that builds/tests without component-model-async, so the legacy path stays green while we work.
Extract the shared async driver into a small wasmtime-async-core crate; both helpers will just wrap it.
Point everything at the new driver and turn the old feature flag into a no-op with a deprecation notice (one-release grace period).
Finish with a bench+docs PR to show no perf regressions and update the book.
Each PR will be bite-sized and fully green on its own, making review and rollback painless.
Let me know if that approach sounds good—happy to tweak anything before I start. Thanks!
shashi1687 edited a comment on issue #11227:
Hi everyone :wave: —I’d love to pick this up.
Quick plan (kept tiny on purpose):
Add a CI lane that builds/tests without component-model-async, so the legacy path stays green while we work.
Extract the shared async driver into a small wasmtime-async-core crate; both helpers will just wrap it.
Point everything at the new driver and turn the old feature flag into a no-op with a deprecation notice (one-release grace period).
Finish with a bench+docs PR to show no perf regressions and update the book.
Each PR will be bite-sized and fully green on its own, making review and rollback painless.
Let me know if that approach sounds good—happy to tweak anything before I start. Thanks!
alexcrichton commented on issue #11227:
@shashi1687 thanks for your interest! Unfortunately though this is probably not a great issue to tackle for you at this time. This is mostly a note to us working on the cm-async bits to come back to this and revisit it. We have some other planned refactorings which may make this issue less relevant, and otherwise the exact shape of a solution for this issue is uncertain. We want to be careful about crate or CI organization so this isn't a great issue to jump in on unfortunately.
shashi1687 commented on issue #11227:
Hi @alexcrichton ,
Thank you very much for taking the time to review my proposal and share such thoughtful feedback—your guidance is always invaluable.
If you have a moment, could you kindly suggest any open issues (or areas that you feel could use attention) where an extra pair of hands might be most helpful? Your perspective on project priorities—and any watch-outs I should keep in mind—would help me choose work that adds real value while staying out of the way.I appreciate any direction you can offer and am, of course, happy to handle the scoping, tests, documentation, and follow-up reviews.
Thanks again for your time and mentorship.
Best regards,
Shashi Shankar
alexcrichton commented on issue #11227:
Thanks for the offer! Unfortunately though this is not something I am good at. While I have visibility on a lot of efforts I have historically never done a good job or known how to do a good job to route newcomers to work items. That's probably not the answer you want to hear, but unfortunately that's the best I can do
Last updated: Dec 06 2025 at 07:03 UTC