[Bug]: HTTP should be explicit about incorrect usage of body/bodyRoot (linter, error, or else)

[lmazuel]

Describe the bug

HTTP do not warn, refuse, or have linter rules about recursively using body or bodyRoot. It was discussed today with @markcowl and @timotheeguerin that this is not a valid pattern, therefore it's suggested that we refuse it.

This may happen unexpectidely when people are using template. Some template of Azure-core for instance include bodyRoot, and any usage of body would fall in this situation, and silently do nothing and be confusing for emitters.

It feels to me that HTTP should be explicit about its behavior, and this is not the case today.

Reproduction

@route("bodyRootWithBody")
op bodyRootWithBody(
  @bodyRoot _: {
    @body body: bytes;
  },
): void;

@route("bodyWithBody")
op bodyWithBody(
  @body _: {
    @body body: bytes;
  },
): void;

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.

[markcowl]

@lmazuel To be clear, I was talking about linters in Azure libraries, not in core libraries, I am not sure that linter rules in the http library itself would be necessary, although perhaps a companion ruleset package is a possibility.

[lmazuel]

I feel it's a problem that the HTTP lib would do silent behavior while decorators are used incorrectly. I expect from a piece of code that if you use it as you shouldn't, you get a clear and actionnable message back that this is not ok. Otherwise, this just leads to confusion (as that happened at the last meeting).

If using recursively those decorators create non-sensical TypeSpec description, as a user I want to know, before I get to weird unexpected emitter behavior (whatever it's client, server, or potentially OpenAPI)

[markcowl]

est: 8