Error Report: 2026-05-24 (735 errors in last 24h)

[claude]

Summary

Authentication timeout dominates errors with 234 occurrences (same users affected), representing expected token lifecycle behavior. Backend API restrictions and user validation errors continue as appropriate patterns. One significant build failure error lacks proper CLI classification.

Metric	Value
Time range	last 24 hours
Total errors	735
CLI bugs	1
Backend issues	4
User errors (working as designed)	6
Unique users affected	308
Internal user occurrences	8

Errors requiring action

1. Build command failures in eject lack proper CLI error classification — CLI bug

Error code	null (missing)
Occurrences	10 (0 internal)
Users affected	10
Command	eject
Platforms	Darwin, Linux
PostHog	View in error tracking
Existing issue	Enhancement #234 (assigned to @kfirstri)
Recurring	Yes (7+ days across multiple reports)

Error: (from PostHog — the actual error message users see)

Command failed with exit code 1: 'npm run build'

✗ Build failed in 417ms
error during build:
[vite:load-fallback] Could not load /src/entities/Score (imported by src/pages/Game.jsx): ENOENT: no such file or directory, open '/src/entities/Score'

Stack trace: (only CLI frames shown)

at runCLI (packages/cli/src/cli/index.ts:59)
at Command.parseAsync (commander library)

Root cause: In the eject command, execa calls for npm install and build commands are not wrapped in proper CLI error handling:

// packages/cli/src/cli/commands/project/eject.ts:164-167
await execa({ cwd: resolvedPath, shell: true })`${installCommand}`;

updateMessage("Building project...");
await execa({ cwd: resolvedPath, shell: true })`${buildCommand}`;

When these commands fail (missing files, permission issues, build errors), raw ExecaError objects bubble up without proper CLI error classification, resulting in null error_code and is_user_error values in telemetry.

Suggested fix: In packages/cli/src/cli/commands/project/eject.ts:164-167, wrap the execa calls in try-catch blocks and throw appropriate CLI error classes (like DependencyInstallationError or BuildFailedError) instead of allowing raw ExecaError to bubble up unclassified.

---

Backend issues (not CLI fixes)

Error	Occurrences	Users	Command	PostHog
Platform restrictions (428)	36	21	deploy, entities push	link
OAuth token expiration (400)	33	56	whoami, dev	link
API server errors (500)	5	2	site open, logs	link
Network/DNS failures	2	2	login	link

Platform restrictions (428): Backend correctly enforces business rules where certain endpoints are only available for Backend Platform apps. CLI properly reports these via standard API error handling.

OAuth errors (400): Token expiration during normal operations where backend returns "expired_token" responses. CLI handles these appropriately by prompting for re-authentication.

Server errors (500): Backend API returning internal server errors for site URL fetching and function logs, indicating backend service issues.

Network failures: DNS resolution failures (getaddrinfo ENOTFOUND app.base44.com) during API calls, representing network connectivity issues.

User errors (working as designed)

Error	Occurrences	Users	Command	PostHog
Authentication timeout	234	234	dev	link
Interactive mode validation	34	17	deploy	link
Project not found validation	31	23	connectors list-available, link	link
Entity schema validation	28	16	functions pull, functions deploy	link
Project already linked	5	4	link	link
Deno dependency validation	7	5	exec	link

AUTH_EXPIRED analysis: High volume from single error type. From packages/cli/src/core/auth/api.ts:83, OAuth token expiration handling:

// packages/cli/src/core/auth/api.ts:83
throw new ApiError(error_description ?? `OAuth error: ${error}`, {
  statusCode: response.status,
});

This triggers when tokens expire naturally. The CLI correctly prompts users to re-authenticate via "Authentication timed out. Please try again."

INVALID_INPUT analysis: Non-interactive mode validation provides actionable error messages like "--yes is required in non-interactive mode" for CI/automation usage.

CONFIG_NOT_FOUND analysis: From packages/cli/src/core/project/app-config.ts:48-50, when findProjectRoot() returns null:

// packages/cli/src/core/project/app-config.ts:48-50
throw new ConfigNotFoundError(
  "No Base44 project found. Run this command from a project directory with a config.jsonc file.",
);

SCHEMA_INVALID analysis: Entity validation provides specific field-level guidance through detailed Zod error messages that help users fix their configurations.

CONFIG_EXISTS analysis: Users trying to link already-linked projects get appropriate validation preventing accidental overwrites.

DEPENDENCY_NOT_FOUND analysis: The CLI properly validates Deno installation and provides clear guidance when the dependency is missing.

Recurring errors

Based on previous daily reports (#521-527), these errors continue from multiple days:

Error	Days recurring	Existing issue	Tracked?
AUTH_EXPIRED timeout	22+ days	Referenced in all previous reports	Yes (expected user behavior)
Backend Platform restrictions	14+ days	Referenced in recent reports	Yes (backend business rules)
Project not found validation	22+ days	Referenced in all previous reports	Yes (expected user error)
Entity schema validation	22+ days	Referenced in all previous reports	Yes (expected user error)
Build command failures in eject	7+ days	Enhancement #234 assigned to @kfirstri	Partially tracked (needs error classification fix)
Interactive mode validation	22+ days	Referenced in all previous reports	Yes (expected user error)
Project linking validation	22+ days	Referenced in all previous reports	Yes (expected user error)
OAuth token expiration	8+ days	Referenced in #522, #525-527	Yes (backend token lifecycle)

The build command failures in eject are tracked for enhancement but the error classification bug needs addressing.

Action items

1. [medium] packages/cli/src/cli/commands/project/eject.ts:164-167 — Wrap execa calls for npm install and build commands in try-catch blocks and throw appropriate CLI error classes (like DependencyInstallationError or BuildFailedError) to ensure proper error classification instead of allowing raw ExecaError to bubble up with null error_code values
2. [low] Backend Platform restrictions (428 errors) and OAuth token expiration represent correct API behavior - users receive appropriate error messages and guidance
3. [low] Backend server errors (500) and network failures indicate infrastructure issues handled correctly by CLI's standard error reporting
4. [low] All user validation errors provide clear guidance and actionable next steps for resolution - no CLI changes needed