Challenge 1: Throw an UNAUTHENTICATED Error — Possible Solution
====================================================================

import { GraphQLError } from "graphql";

Mutation: {
  deletePost: (parent, args, context) => {
    if (!context.currentUser) {
      throw new GraphQLError("You must be logged in to delete a post", {
        extensions: { code: "UNAUTHENTICATED" },
      });
    }

    return db.posts.delete(args.id);
  },
}

WHY THIS WORKS
--------------
- The auth check runs as the VERY FIRST thing inside the resolver,
  before any part of the actual delete logic executes — this guarantees
  that an unauthenticated request can never reach db.posts.delete(...)
  at all, rather than performing the operation and only reporting a
  problem afterward.
- context.currentUser is read from the context object — exactly the
  same object built by the context function from Chapter 6, which this
  chapter noted is also where authentication info belongs alongside
  Chapter 5's DataLoaders. A missing currentUser means the context
  function determined (or was simply never given) a valid authenticated
  user for this request.
- extensions.code: "UNAUTHENTICATED" follows the exact convention this
  chapter introduced for conveying error CATEGORY, since GraphQL itself
  has no HTTP-status equivalent to lean on — a client can check
  error.extensions.code === "UNAUTHENTICATED" specifically to detect
  this case and, for example, redirect the user to a login screen,
  rather than having to parse or guess at the meaning of the plain
  message string.
- The response for this failed mutation would still return HTTP 200,
  with data.deletePost as null and this error appearing in the top-level
  errors array — exactly the response shape this chapter described,
  since a failed authentication check is closer to a systemic/expected
  failure than a payload-level validation error a specific form field
  caused.