calcom/cal.diy · error · HttpError

Session user must have an email

Error message

Session user must have an email

What it means

Defensive guard — the source comment states this "should never happen" because email is part of the session user, but the typings are loose so it is checked explicitly. Fires `HttpError` **400** when a session user exists but has no `email`. It signals a data-integrity or typing gap rather than normal user input.

Source

Thrown at packages/app-store/googlecalendar/api/add.ts:22

import { GOOGLE_CALENDAR_SCOPES, SCOPE_USERINFO_PROFILE, WEBAPP_URL_FOR_OAUTH } from "@calcom/lib/constants";
import { HttpError } from "@calcom/lib/http-error";
import { defaultHandler } from "@calcom/lib/server/defaultHandler";
import { defaultResponder } from "@calcom/lib/server/defaultResponder";

import { encodeOAuthState } from "../../_utils/oauth/encodeOAuthState";
import { getGoogleAppKeys } from "../lib/getGoogleAppKeys";

async function getHandler(req: NextApiRequest, res: NextApiResponse) {
  const loggedInUser = req.session?.user;

  if (!loggedInUser) {
    throw new HttpError({ statusCode: 401, message: "You must be logged in to do this" });
  }

  // Ideally this should never happen, as email is there in session user but typings aren't accurate it seems
  // TODO: So, confirm and later fix the typings
  if (!loggedInUser.email) {
    throw new HttpError({ statusCode: 400, message: "Session user must have an email" });
  }

  const { client_id, client_secret } = await getGoogleAppKeys();
  const redirect_uri = `${WEBAPP_URL_FOR_OAUTH}/api/integrations/googlecalendar/callback`;
  const oAuth2Client = new OAuth2Client(client_id, client_secret, redirect_uri);

  const authUrl = oAuth2Client.generateAuthUrl({
    access_type: "offline",
    scope: [SCOPE_USERINFO_PROFILE, ...GOOGLE_CALENDAR_SCOPES],
    // A refresh token is only returned the first time the user
    // consents to providing access.  For illustration purposes,
    // setting the prompt to 'consent' will force this consent
    // every time, forcing a refresh_token to be returned.
    prompt: "consent",
    state: encodeOAuthState(req),
  });

  res.status(200).json({ url: authUrl });

View on GitHub (pinned to 176037d0af)

Solutions

  1. Ensure the user record has a non-empty email before they reach the integration-install flow (require email at signup/profile).
  2. Fix the session user type so `email` is required, making this guard provably redundant.
  3. If hit, have the affected user complete/update their profile email, then retry the Google install.
Defensive patterns

Strategy: type-guard

Type guard

// Narrow the session user to one guaranteed to have an email before proceeding
import type { Session } from "next-auth";

function hasEmail(user: Session["user"] | undefined): user is { email: string } & NonNullable<Session["user"]> {
  return !!user && typeof user.email === "string" && user.email.trim().length > 0;
}

// usage:
if (!hasEmail(req.session?.user)) {
  // prompt profile completion instead of reaching the 400 in add.ts
}

Prevention

When it happens

Trigger: A logged-in session whose user object lacks `email` — e.g. the underlying `users` row has null/empty email (legacy/migrated data, or email removed post-signup) yet a session was still issued for that user.

Common situations: Migrated/seeded users with no email; sessions created before email became required; an email-change/cleanup flow that nulled email; session typing that marks `email` optional while the code assumes it is present.

Related errors


AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12). Data as JSON: /api/errors/6b1701bd68e88c2c. Report an issue: GitHub.