Pattern Matching on Status Codes | Effect Http Client

When different status codes require different handling, use HttpClientResponse.matchStatus(). It lets you branch your logic based on exact status codes or status code ranges.

1
import {
2
  FetchHttpClient,
3
  HttpClient,
4
  HttpClientRequest,
5
  HttpClientResponse,
6
} from "effect/unstable/http";
7
import { Effect } from "effect";
8

9
function fetchUser(userId: number) {
10
  return Effect.gen(function* () {
11
    const client = yield* HttpClient.HttpClient;
12

13
    const request = HttpClientRequest.get(
14
      `https://dummyjson.com/users/${userId}`,
15
    );
16

17
    const response = yield* client.execute(request);
18

19
    return HttpClientResponse.matchStatus(response, {
20
      // Exact status code
21
      200: (response) =>
22
        Effect.gen(function* () {
23
          const user = yield* response.json;
24
          return `Found user: ${user.firstName} ${user.lastName}`;
25
        }),
26
      404: () => Effect.succeed("User not found"),
27
      // Range matchers for status code classes
28
      "4xx": (response) => Effect.succeed(`Client error: ${response.status}`),
29
      "5xx": (response) => Effect.succeed(`Server error: ${response.status}`),
30
      // Catch-all for any other status
31
      orElse: (response) =>
32
        Effect.succeed(`Unexpected status: ${response.status}`),
33
    });
34
  }).pipe(Effect.flatten, Effect.provide(FetchHttpClient.layer));
35
}
36

37
// Test with different user IDs
38
Effect.runPromise(fetchUser(1)).then(console.log);
39
Effect.runPromise(fetchUser(9999)).then(console.log);

Output:

1
User not found
2
Found user: Emily Johnson

In the example above, we use Effect.flatten because matchStatus is a plain function that returns whatever each branch returns, and our branches return Effects. These returned Effects sit inside the outer Effect.gen, which wraps them in another Effect layer, giving us Effect<Effect<string>>. Effect.flatten unwraps one layer to give us the Effect<string> we need.

matchStatus checks cases in this order: exact status codes first (like 200, 404), then range matchers (“2xx”, “3xx”, “4xx”, “5xx”), and finally orElse as the fallback.

The orElse case is required. This ensures you always handle every possible status code, even unexpected ones.

Exact codes take priority over ranges. In the example above, a 404 response hits the 404 case, not the “4xx” case.

Stay in the loop