[Bug]: Unhelpful error message when missing @added decorator

[mario-guerra]

Describe the bug

I'm revising the pet store example and encountered a cryptic error when I forgot to consistently use the '@added' decorator to specify versioning in operations added for the toy resource.

This code uses two instances of the @added decorator:

   // Operations under the 'toys' namespace are only available in v2 of the API
    @route("{petId}/toys/{toyId}")
    namespace Toys {
        @added(Versions.v2)
        @get
        op getToy(@path petId: int32, @path toyId: int32): OkResponse & {
            @body toy: Toy;
        } | NotFoundResponse & {
            @body error: NotFoundError;
        };
        
        @added(Versions.v2)
        @useAuth(BearerAuth)
        @put
        op updateToy(@path petId: int32, @path toyId: int32, @body toy: Toy): OkResponse & {
            @body updatedToy: Toy;
        } | NotFoundResponse & {
            @body error: NotFoundError;
        };
    }

If I remove the second @added decorator, I get the following error, which doesn't help me determine what the issue is:
error @typespec/openapi3/invalid-schema Couldn't get schema for type never <unknown location>:1:1

Can the error checking be improved to correctly identify the cause?

Reproduction

playground link to error case

playground link to working case

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[timotheeguerin]

Smaller repro Seems to be we are not detecting operation parameters are being a problem if they use a type that is unavailable

[mario-guerra]

Thanks @timotheeguerin. Is the error due to the use of the 'Toy' model which is defined as 'v2' in an op that is implicitly defined as 'v1'?

[timotheeguerin]

yeah, this is a recurring issue we have with versioning there is always other cases where we don't detect that and cause those never values

[mario-guerra]

Is it common enough to have a FAQ entry about in our docs?

[timotheeguerin]

Yeah whenever we fix an issue a little later someone finds a new case where it still happens so could be good to have this in the faq, just very annoying to diagnose

[mario-guerra]

Ok I'll create a FAQ entry for this. Is this issue always related to improper application of versioning?

[timotheeguerin]

Seeing the never type yeah pretty much(unless user actually did use never in that spot but then it should be quite clear to them)