# 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](https://github.com/saif-corp/forge/pull/1214)

Fixes a defect introduced in 3.8.0 ([#904](https://github.com/saif-corp/forge/pull/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](../reference/platform-typespec.md#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 named `type:` argument will fail to compile. The generated constructors no longer accept `type` as a local parameter.
- **Runtime (no compile error):** the generated models still inherit a settable `TypeName` property from `ProblemDetails`, so code that avoids the compile error by setting `instance.TypeName = "..."` after construction will build fine but silently stop seeing `type` in the response body. `HttpServiceExceptionFilter` serializes the constructor-populated `Value` object, not properties set afterward, so a post-construction `TypeName` assignment 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:**

```typespec
model PaymentRequired extends ProblemDetails {
  status: int32 = 402;
  ...StatusCode<402>;
  ...OmitProperties<ProblemDetailsProperties, "title" | "status" | "statusCode">;
}
```

**After:**

```typespec
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](../build/data/database-oracle.md#extending-generated-models-with-partial-classes). Custom models extending `ProblemDetails` must add `"type"` to their `OmitProperties` list. See [C# server-emitter compatibility](../reference/platform-typespec.md#building-custom-status-models).

---

## 📋 Additional Notes

- Total commits: 1
- Files changed: 7
- Contributors: Emmitt Johnson

---

### Support

- 📧 Teams Support Channel: [Support](https://teams.microsoft.com/l/channel/19%3Acb611810fb0b42b080cfff5590bdd51c%40thread.tacv2/Support?groupId=514d2dac-2d62-48ce-bf99-0fa0ce39469c&tenantId=a86cb8ed-369b-4df5-ace5-43811f6e08cf)

---