Filter Hierarchy — Series 3

Preview — 3 of 10 questions

exception.getResponse() returns an object containing a BigInt. What happens?

javascript

catch(exception: HttpException, host: ArgumentsHost) {
  const res = host.switchToHttp().getResponse();
  res.status(exception.getStatus()).json({ error: exception.getResponse(), at: new Date() });
}

AThe BigInt is coerced to a string and the response is sent normally

BThe filter retries with a plain-text body

CSerialisation throws inside the filter, after the status was set but before the body was written — nothing is behind the filter to catch it, so the request ends without a usable response and the original error is never reported

DNest catches the second error and falls back to its default filter

How should a global filter handle both?

javascript

Browser clients expect an HTML error page; API clients expect JSON.

AAlways return JSON and let the browser render it

BRegister two global filters, one per format

CDetect the format from the URL prefix, since /api routes are the JSON ones

DInspect the request's Accept header inside the one filter and branch — returning JSON when the client asks for it and HTML otherwise, with JSON as the fallback for an absent or unrecognised header

What status and shape communicate the outcome best?

javascript

@Post('batch')
async batch(@Body() items: CreateCatDto[]) {
  const results = await Promise.allSettled(items.map((i) => this.cats.create(i)));
  // ???
}

A500, since at least one item failed

B207 Multi-Status (or 200) with a per-item result array — each entry carrying its own success flag, error code and index — because a single status cannot describe a mixed outcome, and a client needs to know precisely which items to retry

C400 with the first error, letting the client retry the whole batch

D202 Accepted with no body, since the work is asynchronous

Answer all 10 questions (7 more), see explanations for every answer, and track your score.