Deprecate execution of "uncomponentizable" WAGI modules

[lann]

My module has been deprecated! What can I do?

This deprecation most likely impacts you only if:

• you are using the WAGI executor, and
• you are not using wit-bindgen, and
• you are using a module compiled with a version of clang < 15.0.7, indicating likely usage of wasi-sdk <19

If you have access to the relevant source code, updating wasi-sdk to at least version 19 can avoid this deprecation.

The Problem

Wasm modules compiled with old versions of wasi-sdk <18 have a bug that makes them incompatible with the wasi-preview1-adapter, which in turn means we cannot convert these modules into components. Maintaining support for executing these uncomponentizable modules represents a significant ongoing maintenance burden, but - as far as we can tell - has been used by very few users, especially recently.

Deprecation Details

We can heuristically detect these modules:

• If a module exports cabi_realloc, it should be safe to componentize, regardless of the version of clang / wasi-sdk
• If a module has a producers section indicating that it was compiled with clang < 15.0.7, it was probably compiled with a buggy version of wasi-sdk

Implementation of this deprecation would include:

• Immediately using the above algorithm to implement a deprecation warning in Spin 2.6 (#2571)
• Actually drop support for these modules when #2519 is merged, possibly motivating a major version bump to Spin 3.0

[michelleN]

@lann For 3.0 - is the action item here mainly documentation at this point or are there other action items?

[michelleN]

Thinking about it more, seems like we'll need an error on spin up as now it's a deprecation notice.

[michelleN]

We'll also want to remove any templates for WAGI apps and templates referencing WAGI including:

• http-php
• http-grain
• http-zig

[itowlson]

The Grain one at least looks like it's been recently fixed to enable componentisation. This doesn't affect all WAGI apps, only ones that can't be componentised (see criteria above) - does the Grain one still fall foul of that?

[lann]

There is an error in place: https://github.com/fermyon/spin/blob/967fdf368612478cef176bccc491faffad680050/crates/componentize/src/bugs.rs#L46-L48

The current Grain template has been fixed but our language docs need to be updated to reflect changes; really we probably ought to validate all of our less-common language docs against 3.0.

[michelleN]

Talked about this at the latest Spin project meeting: Let's make sure this deprecation issue is reflected in documentation before closing this issue.

[vdice]

Re: https://github.com/fermyon/spin/issues/2552#issuecomment-2383994519, the grain and zig templates run fine w/ Spin 3 for me (well, Spin from main as of writing). However, the php template does not. Can we update? If not, do we remove?

$ spin up
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  php-template: http://127.0.0.1:3000 (wildcard)
2024-10-30T21:15:47.165535Z ERROR spin_trigger_http::server: Error processing request: error while executing at wasm backtrace:
    0: 0x6031ea - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::bindings::wasi::cli::exit::exit::h22bf787c004762b4
    1: 0x601aeb - wit-component:adapter:wasi_snapshot_preview1!proc_exit
    2: 0x607f20 - wit-component:shim!adapt-wasi_snapshot_preview1-proc_exit
    3: 0x4f5b15 - <unknown>!<wasm function 5275>
    4: 0x9fe9 - <unknown>!<wasm function 36>
    5: 0x5fa85c - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/[email protected]#run
note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information

Caused by:
    Exited with i32 exit status 1

[lann]

Could you try with WASMTIME_BACKTRACE_DETAILS=1?

[vdice]

Doesn't appear to include any more information, alas:

$ spin up -e WASMTIME_BACKTRACE_DETAILS=1
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  php-template: http://127.0.0.1:3000 (wildcard)
2024-10-30T21:25:35.791411Z ERROR spin_trigger_http::server: Error processing request: error while executing at wasm backtrace:
    0: 0x6031ea - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::bindings::wasi::cli::exit::exit::h22bf787c004762b4
    1: 0x601aeb - wit-component:adapter:wasi_snapshot_preview1!proc_exit
    2: 0x607f20 - wit-component:shim!adapt-wasi_snapshot_preview1-proc_exit
    3: 0x4f5b15 - <unknown>!<wasm function 5275>
    4: 0x9fe9 - <unknown>!<wasm function 36>
    5: 0x5fa85c - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/[email protected]#run

Caused by:
    Exited with i32 exit status 1

[lann]

Ah sorry, the env var should actually be in spin's environment, e.g. just WASMTIME_BACKTRACE_DETAILS=1 spin up

[vdice]

No luck :(

$ WASMTIME_BACKTRACE_DETAILS=1 spin up
Logging component stdio to ".spin/logs/"

Serving http://127.0.0.1:3000
Available Routes:
  php-template: http://127.0.0.1:3000 (wildcard)
2024-10-30T21:40:21.868509Z ERROR spin_trigger_http::server: Error processing request: error while executing at wasm backtrace:
    0: 0x6031ea - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::bindings::wasi::cli::exit::exit::h22bf787c004762b4
    1: 0x601aeb - wit-component:adapter:wasi_snapshot_preview1!proc_exit
    2: 0x607f20 - wit-component:shim!adapt-wasi_snapshot_preview1-proc_exit
    3: 0x4f5b15 - <unknown>!<wasm function 5275>
    4: 0x9fe9 - <unknown>!<wasm function 36>
    5: 0x5fa85c - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/[email protected]#run

Caused by:
    Exited with i32 exit status 1

[lann]

Ok not too surprising; thanks for trying. I can try something else but we might need to drop php.

[vdice]

Was preparing to remove the php template when I noticed that we have test coverage for this one -- and it appears to be passing:

test integration_tests::http_php_template_smoke_test ... ok from the most recent CI run https://github.com/fermyon/spin/actions/runs/11603532469/job/32486378143

Thoughts on how/why?

[lann]

Turns out we were holding it wrong; you have to include the php file in the URL, e.g. http://localhost:3000/index.php. Not a good UX both in terms of not supporting an empty path and in terms of the completely opaque error message, but I don't think this is a regression.

[vdice]

D'oh! Thanks @lann.

What's our plan with this issue? Keep open for tracking? Close out now that the implementation work is in?

[lann]

This issue is linked by a Spin error message if we detect these modules but I think we can close and I'll just add a note to the top.