Validate HTTP routes are unique

[itowlson]

Spin currently permits non-unique HTTP routes, e.g. this loads without complaint:

[[component]]
id = "hello1"
source = "target/wasm32-wasi/release/spinhelloworld.wasm"
[component.trigger]
route = "/hello"

[[component]]
id = "hello2"
source = "target/wasm32-wasi/release/spinhelloworld.wasm"
[component.trigger]
route = "/hello"

This is overwhelmingly likely to be an error, and should be rejected, or at the very least should receive a trace message at an on-by-default level.

(~We should also document the behaviour of overlapping routes, e.g. /... and /static/... - I don't think we have that yet, though could be wrong!~ [ETA: I was, indeed, wrong.] It would also be good to error or warn if a route can never be matched.)

[radu-matei]

You are right, this is part of the larger discussion around how we handle exact and wildcard routes.

There is a brief mention in the HTTP trigger docs about what happens in the case of overlapping routes:

https://github.com/fermyon/spin/blob/ea7f8ee197128d455aeeae3a0f460d2652b77602/docs/content/http-trigger.md?plain=1#L65-L86

[itowlson]

👍 Thanks - removed that remark from the issue!

[ghost]

One path would be to essentially duplicate the work from https://github.com/fermyon/spin/pull/370 and add a constraint for unique routes. There’s probably an opportunity there to generalize the idea of constraints which may be useful in the future depending on how the Spin configuration evolves (but maybe out of scope for this task?)

If any other new contributors are interested I’d be happy to help - otherwise I can tackle this later.

I am curious to hear thoughts on whether a refactor to add a generalized configuration constraint mechanism is desirable.

[itowlson]

@0xcodeboi Some sort of infrastructure that would allow a manifest to be run through a set of validators seems sensible. As you note, it might be more long term, though I don't think it would create significant extra work or complexity to do something simple on day one. A good infrastructure would set us up to do good things like accumulate a full list of failures (rather than stopping on the first one) so that new validations would just play into that good behaviour; but yes, this does bring up questions of scope!

This particular validation would be specific to the trigger, so we would likely need (at least) two sets of validations: one for the bits the Spin loader/engine cares about (like the component IDs), and one for the bits the current trigger cares about (like the HTTP trigger cares about routes). I can see it making sense for host component and dependency configurations too. We'd need to figure out how to organise those in an intelligible way.

Are you keen to tackle this? If not, I might look at it with a view to setting up a generaliseed infrastructure. But if you're keen, then I'm happy to leave it for you! I certainly have plenty of other stuff on my plate right now...!