3.9.3¶
Release Date: September 21, 2026
🐛 Bug Fixes¶
NPM Packages¶
Fix type dropped from Kiota-generated error clients in @saif/platform-typespec 📦¶
Package: @saif/platform-typespec
PR: #1214
Fixes a defect introduced in 3.8.0 (#904) where Kiota-generated C# clients have no Type property on any error model (BadRequest, NotFound, and the rest).
Kiota reparents error models onto ApiException and discards the ProblemDetails base, deduplicating away any property declared on both the base and a concrete error model. #904 fixed an equivalent regression for status by moving it off the base, but anchored the base body with type instead — leaving type declared in both the base and every concrete model. That duplication compiles cleanly and fails silently: it produces no build error, just a client with a missing property.
type now lives only on the ProblemDetails base; all 41 concrete error models omit it from their ProblemDetailsProperties spread. foundations.tsp documents the resulting invariant, and the existing Kiota regression test was extended to guard both directions.
Action required:
Update to @saif/platform-typespec 3.9.3 or later and republish the OpenAPI document, then regenerate any Kiota clients. Custom error models that extend ProblemDetails directly must add "type" to their OmitProperties list — see Building custom status models.
🔄 Breaking Changes¶
C# server-emitter constructor signature for concrete error models¶
Package: @saif/platform-typespec
Consumers who generate C# server-side models from this library with @typespec/http-server-csharp are affected in two distinct ways after regenerating:
- Compile-time: hand-constructing one of the 41 concrete error models (
BadRequest,NotFound, and the rest) with a namedtype:argument will fail to compile. The generated constructors no longer accepttypeas a local parameter. - Runtime (no compile error): the generated models still inherit a settable
TypeNameproperty fromProblemDetails, so code that avoids the compile error by settinginstance.TypeName = "..."after construction will build fine but silently stop seeingtypein the response body.HttpServiceExceptionFilterserializes the constructor-populatedValueobject, not properties set afterward, so a post-constructionTypeNameassignment never reaches the wire. This case is more dangerous because nothing signals it at build time.
The OpenAPI wire contract and Kiota-generated client code are unaffected; both impacts are limited to server-emitted models.
Custom TypeSpec models that extend ProblemDetails directly must also add "type" to their OmitProperties list, or they will reproduce the client-side bug this release fixes.
Before:
model PaymentRequired extends ProblemDetails {
status: int32 = 402;
...StatusCode<402>;
...OmitProperties<ProblemDetailsProperties, "title" | "status" | "statusCode">;
}
After:
model PaymentRequired extends ProblemDetails {
status: int32 = 402;
...StatusCode<402>;
...OmitProperties<ProblemDetailsProperties, "title" | "status" | "statusCode" | "type">;
}
Migration: Remove any named type: argument from hand-constructed calls to generated error model constructors; the compiler will reject it until you do. There is no generated replacement: the emitter builds each concrete model's constructor only from that model's own locally declared properties (inherited base properties are dropped), and leaf error models never receive the base class's raw (statusCode, value, headers) pass-through constructor, so nothing on any concrete model can carry type into the response body. Setting the inherited TypeName property after construction is equally a dead end — it compiles, but HttpServiceExceptionFilter serializes the constructor-populated Value object, not properties set afterward, so type never reaches the wire either way. Consumers who need a specific type value in a response must add their own hand-written partial class for the affected model(s) with a constructor overload that builds its own value: new { type = ..., ... } object literal, following the partial-class pattern used for other generated models. Custom models extending ProblemDetails must add "type" to their OmitProperties list. See C# server-emitter compatibility.
📋 Additional Notes¶
- Total commits: 1
- Files changed: 7
- Contributors: Emmitt Johnson
Support¶
- 📧 Teams Support Channel: Support