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/http-trigger@2.0.0 (https://github.com/fermyon/spin/blob/3e62d2e358d2aaa66563e55cffdad5ecd5dc0f4d/wit/world.wit#L4) or fermyon:spin/http-trigger-rc20231018@2.0.0 (https://github.com/fermyon/spin/blob/3e62d2e358d2aaa66563e55cffdad5ecd5dc0f4d/wit/world.wit#L10).

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/incoming-handler@0.2.0-rc-2023-10-18 (which is available only in the fermyon:spin/http-trigger-rc20231018@2.0.0 world), but imports wasi:filesystem/types@0.2.0 and other WASI 0.2 interfaces (which are only available in the fermyon:spin/http-trigger@2.0.0 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/poll@0.2.0-rc-2023-10-18;
  import wasi:io/streams@0.2.0-rc-2023-10-18;
  import wasi:http/types@0.2.0-rc-2023-10-18;
  import wasi:http/outgoing-handler@0.2.0-rc-2023-10-18;
  import fermyon:spin/llm@2.0.0;
  import fermyon:spin/redis@2.0.0;
  import fermyon:spin/rdbms-types@2.0.0;
  import fermyon:spin/postgres@2.0.0;
  import fermyon:spin/mysql@2.0.0;
  import fermyon:spin/sqlite@2.0.0;
  import fermyon:spin/key-value@2.0.0;
  import fermyon:spin/variables@2.0.0;

  export wasi:http/incoming-handler@0.2.0-rc-2023-10-18;
}

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/poll@0.2.0-rc-2023-10-18;
  import wasi:io/streams@0.2.0-rc-2023-10-18;
  import wasi:http/types@0.2.0-rc-2023-10-18;
  import wasi:cli/environment@0.2.0;
  import wasi:cli/exit@0.2.0;
  import wasi:io/error@0.2.0;
  import wasi:io/streams@0.2.0;
  import wasi:cli/stdin@0.2.0;
  import wasi:cli/stdout@0.2.0;
  import wasi:cli/stderr@0.2.0;
  import wasi:cli/terminal-input@0.2.0;
  import wasi:cli/terminal-output@0.2.0;
  import wasi:cli/terminal-stdin@0.2.0;
  import wasi:cli/terminal-stdout@0.2.0;
  import wasi:cli/terminal-stderr@0.2.0;
  import wasi:clocks/wall-clock@0.2.0;
  import wasi:filesystem/types@0.2.0;
  import wasi:filesystem/preopens@0.2.0;

  export wasi:http/incoming-handler@0.2.0-rc-2023-10-18;
}

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/http-trigger@2.0.0 (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.