The kernel exports a shared Result pattern and helpers such as ok and handleActionError, alongside an AppError taxonomy. Authentication actions use these helpers to return typed outcomes instead of exposing unhandled exceptions to the caller.
Prefer explicit action results#
When calling a Veap action, inspect the returned result according to the package's declared Result<T> type. Do not assume a successful action always returns the entity directly; the result may wrap it.
import { signIn } from "@veap/auth";
const result = await signIn({ email, password });
if (!result.success) {
// Present a safe user-facing message; log details on the server.
return { success: false };
}
return { success: true };Use the exact result shape declared by the installed kernel version. This example illustrates control flow and intentionally avoids inventing a full error payload schema.
Error categories#
The kernel's error exports include common application categories such as not found, unauthorized, forbidden, validation, and conflict errors. Choose an error that reflects the actual failure. Do not return stack traces, SQL details, secrets, tokens, or internal exception messages to clients.
Next.js control-flow errors#
The application bootstrap and event bus explicitly preserve Next.js redirect and not-found control-flow errors in inspected code paths. When integrating Veap with Next.js, do not indiscriminately catch and convert every thrown value into a generic error; doing so can break framework navigation behavior.
Logging#
Log unexpected failures on the server with request or operation context, but avoid logging passwords, session tokens, recovery codes, or full sensitive request bodies. Use stable error codes for user-facing responses and detailed diagnostics only in protected logs.
