wasi-virt throws error in wasm-compose (redirected from wasi-virt to Wasm-tools)

[thesuhas]

Hi,

I'm trying to use wasi-virt with a micro service that I have written in rust. I want to give it a pre-opened file directory so that I can read a json file.
I am using this command: wasi-virt --debug --stderr=allow composed-cinema.wasm --preopen microservices/cinema-1/users=/data --allow-http -o virt-cinema.wasm
And I get the following error:

It seems to be an error in wasm-compose. For some additional context, the micro service was composed by using the http@3.0 draft from here.

I initially posted this in wasi-virt but was redirected here as it was an issue stemming from wasm-tools.

[rvolosatovs]

Looks like I just hit the same issue #1811

[alexcrichton]

Would it be possible to get a standalone invocation of wasm-tools compose to reproduce this @rvolosatovs perhaps? (or @thesuhas, but I realize it's been awhile since you originally opened this). If that's possible it might be best to try out such an invocation with wac as well. If it works in wac and doesn't work with wasm-compose then the best solution here is to probably migrate wasi-virt to wac instead of wasm-compose.

[brian14708]

I’ve been encountering a similar problem. When custom component functions references wasi: resources, it will fail to compose with wasi-virt.

Here is a minimal reproducible example: https://github.com/brian14708/wasm-tools-1565

[elewis787]

@jeff1010322 and I are also experiencing a similar error, We have updated bytecodealliance/wac#149 with another reproducible example that is not leveraging wasi resources at https://github.com/hayride-dev/compose-bug

Are there any resources available to better understand the contextually_unique_id, and if resources are able to be imported along side other imports that may leverage the same resource?

So far, I have only found a few details here

wasm-tools/crates/wasmparser/src/validator/component_types.rs

Lines 1280 to 1284 in 351f153

	// The 32-bit storage here should ideally be enough for any component
	// containing resources. If memory usage becomes an issue (this struct is
	// 12 bytes instead of 8 or 4) then this could get folded into the globally
	// unique id with everything using an atomic increment perhaps.
	contextually_unique_id: u32,

[alexcrichton]

AFAIK the errors here are "legitimate", so this is an issue of developer tooling, error messages, conventions, etc.

@brian14708 looking at your example repo (sorry I realize this is 6 months after you posted) what I see is that the component has:

world root {
    import wasi:io/poll@0.2.1;
    // ...
    import my-sleep: func() -> pollable;
}

You're then "plugging" in a virt.wasm with wac, and that's given a resource error:

error: encoding produced a component that failed validation

Caused by:
    type mismatch for import `pollable`
    resource types are not the same (ResourceId { globally_unique_id: 2, contextually_unique_id: 1 } vs. ResourceId { globally_unique_id: 2, contextually_unique_id: 110 }) (at offset 0x21b6fa)

this is, unfortunately, expected. The type of the component requires that the pollable resource supplied to my-sleep is the exact same one supplied to wasi:io/poll. During the "plug" process though the import of wasi:io/poll is satisfied by virt.wasm, but then the import of my-sleep is propagated to the outer final component which imports a different wasi:io/poll, one from the host. This difference is why the resource types are not the same here. There is no way to solve this realistically with WASI 0.2. If you're importing my-sleep from the host then that means you must import wasi:io/poll from the host as well. That means the virt.wasm must not export it. However practically all WASI interfaces import from wasi:io/poll which means you practically can't export anything from virt.wasm, defeating the purpose of virtualization.

There's various ways to slice and dice this as to how to solve it here-and-now, but most of them involve going back to the drawing board. For example maybe virt.wasm could virtualize my-sleep too. Or maybe virt.wasm isn't necessary to export everything (e.g. if you just want, say, env vars). Or maybe you do want this all to work in which case WASI 0.3, with the removal of wasi:io/poll, is maybe what you want.

---

@elewis787 My guess is that your use case falls more-or-less in this category as well. I don't have TinyGo installed, however. Can you provide component binaries plus a wac command I can run? I can try to explain what the resource mismatch is given that.

[elewis787]

@alexcrichton, the wasm binaries can now be found in the repo https://github.com/hayride-dev/compose-bug

In the example, we create 3 components

• foo: exports the foo interface, which defines a foo resource.
• foo-bar: exports the foo-bar interface, which defines a foo-bar resource that uses foo.
• foo-bar-baz: imports both foo and foo-bar, and creates a command component that exports the CLI run functions. Uses foo and foobar to build a "foo-bar-baz" string.

The flow is to build foo, foo-bar, and foo-bar-baz as components, then use WAC to compose them together.

wac plug foo-bar.wasm --plug foo.wasm -o foo-bar-composed.wasm
wac plug foo-bar-baz.wasm --plug foo-bar-composed.wasm -o foo-bar-baz-composed.wasm

In the above example, foo-bar and foo are successfully plugged.

However, when attempting to plug foo-bar-composed.wasm with foo-bar-baz.wasm, the following error is triggered

error: encoding produced a component that failed validation

Caused by:
    type mismatch for import `compose:lib/foo-bar@0.0.1`
    type mismatch in instance export `foo-resource`
    resource types are not the same (ResourceId { globally_unique_id: 2, contextually_unique_id: 51 } vs. ResourceId { globally_unique_id: 2, contextually_unique_id: 1 }) (at offset 0x15d26f)
make: *** [wac-foo-bar-baz] Error 1

There are changes to the flow of resources that could be made to avoid this, but the main question is whether this pattern or a similar pattern is expected to be possible.

[alexcrichton]

The problem you're running into @elewis787 is unforutnately surprisingly subtle. In the second wac plug example what I see is that foo-bar-composed.wasm exports this interface:

package compose:lib@0.0.1 {
  interface foo-bar {
    resource foo-resource;

    resource foo-bar-resource {
      constructor();
      foo-bar: func(f: foo-resource) -> string;
    }
  }
}

where foo-bar-baz.wasm imports this interface:

package compose:lib@0.0.1 {
  interface foo-bar {
    use foo.{foo-resource};

    resource foo-bar-resource {
      constructor();
      foo-bar: func(f: foo-resource) -> string;
    }
  }
}

These are entirely different definitions where the first defines a resource named foo-resource and the second imports it from a sibling interface. That's why validation of the final component is failing. Thus the problem lies in the creation of foo-bar-baz.wasm.

The creation of foo-bar-baz.wasm is, however, unfortunately flawed. The foo-bar.wasm base component looks like this:

world root {
  // ...
  import compose:lib/foo@0.0.1;

  export compose:lib/foo-bar@0.0.1;
}

// ...

package compose:lib@0.0.1 {
  interface foo {
    resource foo-resource {
      foo: func() -> string;
    }
  }
  interface foo-bar {
    use foo.{foo-resource};

    resource foo-bar-resource {
      constructor();
      foo-bar: func(f: foo-resource) -> string;
    }
  }
}

where the component you're plugging, foo.wasm, looks like this:

world root {
  // ...

  export compose:lib/foo@0.0.1;
}


package compose:lib@0.0.1 {
  interface foo {
    resource foo-resource {
      constructor();
      foo: func() -> string;
    }
  }
}

While this seemingly seems valid it's not actually possible to "plug" this example while preservingt he same types. The foo-bar fundamentally must refer to another interface in the world, imported or exported. Thus it's not possible to export foo-bar without referring to either an import or import without changing the meaning of the interface. That's what's happening here is that the meaning of the interface is changing during the first wac plug step where the resource is simply defined rather than inferred.

This is arguably a bug in wac where the foo interface should be exported as a result of the first plug operation, for example. Either that or wac should produce an error or somehow prevent the first plug. This is, however, a pretty subtle issue and would be, I suspect, quite difficult to implement.

I think, however, that wac is capable of solving this problem today. For example using this input:

// compose.wac
package example:composition;

let foo = new my:foo { ... };
let foo-bar = new my:foo-bar {
  foo: foo.foo,
  ...
};
let foo-bar-baz = new my:foo-bar-baz {
  foo: foo.foo,
  foo-bar: foo-bar.foo-bar,
  ...
};

export foo-bar-baz...;

I can run:

$ wac compose foo.wac --dep my:foo=./foo.wasm --dep my:foo-bar=./foo-bar.wasm --dep my:foo-bar-baz=./foo-bar-baz.wasm
error: failed to resolve document

  × instance has no exports or all exports of the instance match previously exported names
    ╭─[foo.wac:14:8]
 13 │
 14 │ export foo-bar-baz...;
    ·        ─────┬─────
    ·             ╰── spreading the exports of this instance has no effect
    ╰────

This happens because foo-bar-baz.wasm doesn't actually have any exports, but I believe if you added an export then this should work (or something like it, I'm not sure that the wac script is 100% right)

[elewis787]

Thanks @alexcrichton! We updated the wit world of foo-bar-baz to correctly export cli/run for the example - sorry about that.

Doing this, we can use the composition script to avoid the error we are running into with plug. The example repo has been updated to reflect the changes.

Appreciate the help and details as always!