Various Issues encountered with Microcks

[kierank1]

Hey folks, I'm beginning to work with Microcks and have noticed a couple of issues.

1. Script Dispatcher Fails with latest-native image

When running Microcks as a docker image, the latest microcks-uber:latest-native always gives an error when attempting to resolve a script dispatcher. It'd be great if either:

• The documentation is updated to reflect this
• The latest-native image is updated to support this behaviour

2. Inconsistent ordering of mocks

When uploading my OpenAPI schema file through the Microcks UI, the order of the mocks seems to be entirely random.

First upload

Second upload

This causes some issues, as Microcks by default is returning the first mock it receives, which appears to be the first mock list in the UI. I'd expect the mocks to be provided in the order they are listed in the examples in my OpenAPI Schema.

Is there something I'm potentially missing here? Is this a bug? I'm able to work around it by setting up dispatchers that will have reliable defaults, but this was a bit of a headache to figure out when I first got started.

[lbroudoux]

Hey @kierank1

Sorry for the latency in reply... and sorry you're bothered with some issues... Let me give you some answers:

1. Script Dispatcher Fails with latest-native image

Yes, this is totally expected. This is actually documented here, in some blog posts announcements, discussed there and some other places. Would you have a suggestion on how to make this more visible? What was the learning trail you followed and where you missed this information?

2. Inconsistent ordering of mocks

There's actually no notion of sample order when importing one or many artifacts. If you need to have reliable defaults, I recommend having a look at the FALLBACK dispatcher that will allow you to control what's returned when something goes wrong. Please check https://microcks.io/documentation/explanations/dispatching/#fallback-dispatcher

Here again, do you have a suggestion on where we could add this information so that beginners won't be annoyed on this topic?

Cheers,

[kierank1]

Thanks for the reply @lbroudoux.

I had found in the Getting Started guide that it lists the native image to utilize - I would recommend changing this to the standard image, so that all of the features are present immediately, rather than a limited (albeit more performative) subset. Or making a note of this limitation in the Getting Started section, or even a link to the other container options would be good as well.

I did find out that the FALLBACK dispatcher controls the default, but there wasn't anything indicating what would happen if there is no inferred or explicit dispatchers present, which is a fairly common edge case. I think an additional warning or note under Inferred dispatchers that indicates this behaviour if you have more than one example would be useful.

Cheers.