[Spector] Add 200 body / 204 no-content success response scenario

[JoshLove-msft]

Scenario

Add an HTTP Spector scenario for an operation whose successful response may either contain a model body or contain no body:

op getLayout(): {
  @statusCode statusCode: 200;
  @body layout: BlobLayout;
} | {
  @statusCode statusCode: 204;
};

The scenario should provide test routes/cases that exercise both declared outcomes:

• 200 OK with a valid BlobLayout response body.
• 204 No Content with no response body.

Why

Emitters need to distinguish this from a nullable body on a single response. The operation succeeded in both cases, but one success variant has no representation. Without shared Spector coverage, emitters can accidentally deserialize the empty 204 response or expose a result type that incorrectly guarantees a value.

Validation

The scenario should allow language emitters to verify that:

• Both 200 and 204 are classified as successful.
• The 200 response is deserialized normally.
• The 204 response does not attempt body deserialization.
• Raw response status and headers remain available for both outcomes.

[github-actions]

🎯 Issue Triage

Feature request to add a new HTTP Spector scenario covering operations that return either a 200 response with a body or a 204 response with no body. This ensures emitters correctly handle the distinction between a nullable body and an optional body across success variants.

Category: Feature Request
Area: lib:http-specs

🔍 Analysis

• The scenario targets @typespec/http-specs (Spector), not the compiler or individual emitters.
• The core concern is ensuring emitters don't accidentally deserialize a 204 No Content response when the operation can also return 200 with a body.
• Without this shared scenario, each client emitter would need to independently test and validate this pattern.
• Validation requirements are clearly specified: both variants classified as successful, 200 deserialized normally, 204 skips body deserialization, raw response accessible for both.

📝 Suggested next steps

• Add a BlobLayout model and getLayout operation to @typespec/http-specs
• Implement mock API routes for both the 200 (with body) and 204 (no body) cases
• Annotate the scenario with @scenario and @scenarioDoc
• Verify all client emitters pass the new scenario

Generated by Agentic Triage