Skip to lesson
Exit
Coding & Engineering Craft: TS, Rust, Python on the Hot Path1 / 2

1 min lesson

TypeScript at depth

Make the call in this situation: "In TypeScript, why deliberately omit a default branch when switching over a discriminated union of provider outcomes?" Explain what supports it.

Step 1 of 2

TypeScript at depththe default for gateway work

If you pick TypeScript, the bar is not “I write React.” It is modeling a provider abstraction in the type system so that an impossible state cannot compile. The single most reusable pattern for an inference gateway is a discriminated union over provider outcomes plus an exhaustive switch that the compiler forces you to keep complete.

Model every upstream outcome as one tagged union; let strict mode enforce exhaustiveness.ts
type ProviderResult<T> =
  | { kind: "ok"; value: T; tokensIn: number; tokensOut: number }
  | { kind: "rateLimited"; retryAfterMs: number }
  | { kind: "timeout" }
  | { kind: "upstreamError"; status: number; retryable: boolean };

function classify<T>(r: ProviderResult<T>): "retry" | "failover" | "return" {
  switch (r.kind) {
    case "ok":           return "return";
    case "rateLimited":  return "failover";
    case "timeout":      return "retry";
    case "upstreamError":return r.retryable ? "retry" : "failover";
    // no default: adding a new variant becomes a compile error here.
  }
}
Why no default case

Omitting default on an exhaustive switch turns “we added a new provider outcome and forgot to handle it” from a 2am incident into a red squiggle. Narrating that tradeoff out loud is worth more than the code itself - it shows you reach for the type system to prevent classes of bugs, not just to annotate.