Mismatch between the Spin WIT and the effective Spin world

[itowlson]

As part of the target environment validation project, I try to validate that (componentised and resolved) Wasm components conform to one of the supported Spin worlds for their trigger. For example, a HTTP component should conform to fermyon:spin/[email protected] (

spin/wit/world.wit

Line 4 in 3e62d2e

world http-trigger {

) or fermyon:spin/[email protected] (

spin/wit/world.wit

Line 10 in 3e62d2e

world http-trigger-rc20231018 {

).

However, the fileserver 0.3 component (built with Spin SDK 2.x) does not conform to either of these worlds, because (again, once componentised) it exports wasi:http/[email protected] (which is available only in the fermyon:spin/[email protected] world), but imports wasi:filesystem/[email protected] and other WASI 0.2 interfaces (which are only available in the fermyon:spin/[email protected] world). This is possibly an artefact of spin-componentize producing a hybrid, I am not sure.

Whatever the cause, the upshot is that attempting to validate the fileserver against either of the Spin HTTP worlds fails. If we implemented target validation using the current worlds, we would be telling people that the fileserver doesn't work. Which it does. Like a boss.

So, since this hybrid works, should the Spin world reflect that? That is, should the rc world import WASI 0.2 as well as WASI rc, and should the 'release' world import WASI rc as well as WASI 0.2?

Or is it correct that a component should fit entirely within one of these worlds, and this is merely a componentisation glitch with RC modules?

Additional context

The fileserver world before componentisation:

$ wasm-tools component wit spin_static_fs.wasm
package root:root;

world root {
  import wasi:io/[email protected];
  import wasi:io/[email protected];
  import wasi:http/[email protected];
  import wasi:http/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];
  import fermyon:spin/[email protected];

  export wasi:http/[email protected];
}

This appears to conform to the rc world.

The fileserver world after componentisation:

$ wasm-tools component wit COMPY-assets.wasm
package root:component;

world root {
  import wasi:io/[email protected];
  import wasi:io/[email protected];
  import wasi:http/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:io/[email protected];
  import wasi:io/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:cli/[email protected];
  import wasi:clocks/[email protected];
  import wasi:filesystem/[email protected];
  import wasi:filesystem/[email protected];

  export wasi:http/[email protected];
}

This appears to require imports from both worlds (which works, but does not conform to either WIT).

cc @tschneidereit

[rylev]

This certainly strikes me as a bug somewhere. The Spin runtime supports running both worlds which effectively means it can support the union of all imports from those two worlds. However, if another runtime wanted to run Spin applications but only wanted to support the fermyon:spin/[email protected] (a very reasonable thing to do), it would not be able to run this application.

I think ideally, we would perhaps warn in situations like this. The warning should state that the application can run, but that it's a compatibility hazard since the application may not run on other runtimes since it is not conforming to a known world.