Error Report: 2026-02-19 (9 errors in last 48h)

[claude]

Summary

The last 48 hours show 388 total errors across 9 error types affecting 148 unique users. System errors represent the most critical issues with function deployment timeouts and authentication failures requiring immediate attention. User errors indicate potential usability issues with project setup and configuration workflows.

Key Metrics

Metric	Value
Time range	last 48 hours
Total errors	388
System errors	124
User errors (noteworthy)	264
Unique users affected	148
Internal user occurrences	73

Recurring Errors

This is the first automated error report - no previous data available for comparison.

Critical Issues

Issue 1: Function Deployment Timeout and Validation Failures

Error code: API_ERROR | Occurrences: 105 | Users affected: 39
Command: functions deploy | Type: System
Recurring: No | Existing issue: None
PostHog: View in error tracking

Error from PostHog:

ApiError: Function deployment errors:
'update-slack-status' function: Deno deployment failed: Operation wait_for_deployment(update-slack-status) timed out after 90 seconds

Stack trace (from PostHog, abbreviated):

ApiError: Error deploying functions: Validation failed
    at runCLI (src/cli/index.ts:32:4)
    at Command.parseAsync (node_modules/commander/lib/command.js:1091:4)

What happened:
Function deployments are failing due to server-side timeouts and validation errors when deploying Deno functions to the Base44 backend.

Root cause in code:
The CLI makes a PUT request to /backend-functions with no client-side timeout. Server-side deployment operations are timing out after 90 seconds:

// src/core/resources/function/api.ts:29-32
response = await appClient.put("backend-functions", {
  json: payload,
  timeout: false, // No client timeout, relies on server
});

When deployment fails, the CLI throws an ApiError with the server's error message:

// src/cli/commands/functions/deploy.ts:42-50
if (result.errors && result.errors.length > 0) {
  const errorMessages = result.errors
    .map((e) => `'${e.name}' function: ${e.message}`)
    .join("\n");
  throw new ApiError(`Function deployment errors:\n${errorMessages}`);
}

Additional context:

• CLI versions: 0.0.32
• Platforms: macOS (arm64), Windows (x64), Linux (x64)
• Internal vs external: 29 of 105 occurrences from internal users
• 422 and 428 HTTP status codes indicate validation and precondition failures

Expected behavior: Functions should deploy successfully or provide clearer error messages about deployment requirements
Actual behavior: Functions fail to deploy with timeout and validation errors

---

Issue 2: Authentication Timeout Failures

Error code: None (generic Error) | Occurrences: 39 | Users affected: 36
Command: whoami, login, create, entities push | Type: System
Recurring: No | Existing issue: None
PostHog: View in error tracking

Error from PostHog:

Error: Authentication timed out. Please try again.

Stack trace (from PostHog, abbreviated):

Error: Authentication timed out. Please try again.
    at runCLI (src/cli/index.ts:32:4)
    at Command.parseAsync (node_modules/commander/lib/command.js:1091:4)

What happened:
Authentication operations are timing out, affecting users trying to log in or perform authenticated actions.

Root cause in code:
Authentication timeouts originate from the CLI's auth flow, but the specific timeout mechanism is not visible in the CLI entry point. The error is caught and reported through the standard error handling:

// src/cli/index.ts:33-44
try {
  await program.parseAsync();
} catch (error) {
  if (!(error instanceof CLIExitError)) {
    const errorObj = error instanceof Error ? error : new Error(String(error));
    errorReporter.captureException(errorObj);
  }
  process.exitCode = error instanceof CLIExitError ? error.code : 1;
}

Additional context:

• CLI versions: 0.0.32
• Platforms: Linux (x64) primarily
• Internal vs external: 4 of 39 occurrences from internal users
• Affects basic authentication workflows

Expected behavior: Authentication should complete successfully or provide clear retry instructions
Actual behavior: Authentication times out with generic error message

---

Issue 3: High Volume Project Configuration Not Found

Error code: CONFIG_NOT_FOUND | Occurrences: 91 | Users affected: 35
Command: link, deploy, functions deploy, dev | Type: User (High Volume)
Recurring: No | Existing issue: None
PostHog: View in error tracking

Error from PostHog:

ConfigNotFoundError: No Base44 project found. Run this command from a project directory with a config.jsonc file.

Stack trace (from PostHog, abbreviated):

ConfigNotFoundError: No Base44 project found. Run this command from a project directory with a config.jsonc file.
    at runCLI (src/cli/index.ts:32:4)

What happened:
Users are running Base44 commands outside of project directories, resulting in high volumes of configuration not found errors.

Root cause in code:
The project discovery walks up the directory tree looking for config files but throws an error if none are found:

// src/core/project/config.ts:73-76
if (!found) {
  throw new ConfigNotFoundError(
    `Project root not found. Please ensure config.jsonc or config.json exists in the project directory or ${PROJECT_SUBDIR}/ subdirectory.`,
  );
}

Additional context:

• CLI versions: 0.0.32
• Platforms: All platforms affected
• Internal vs external: 11 of 91 occurrences from internal users
• This user error has high volume suggesting potential UX improvement opportunities

Expected behavior: Users understand where to run Base44 commands
Actual behavior: High volume of users running commands in wrong directories

---

Issue 4: Entity Schema Validation Failures

Error code: SCHEMA_INVALID | Occurrences: 46 | Users affected: 26
Command: entities push, deploy | Type: User (High Volume)
Recurring: No | Existing issue: #233 (related but different - agent name validation)
PostHog: View in error tracking

Error from PostHog:

SchemaValidationError: Invalid entity file in /Users/<redacted>/Documents/Base44/prop-sync-new/base44/entities/Approval.jsonc:
✖ Invalid input: expected "object"
  → at type
✖ Invalid input: expected string, received undefined
  → at name

Stack trace (from PostHog, abbreviated):

SchemaValidationError: Invalid entity file in /Users/<redacted>/...
    at runCLI (src/cli/index.ts:32:4)

What happened:
Users have invalid entity definition files that fail Zod schema validation, particularly with RLS (Row Level Security) configurations and basic required fields.

Root cause in code:
Entity files are validated against strict Zod schemas, and validation errors are formatted with detailed messages:

// src/core/errors.ts:226-237
constructor(context: string, zodError: z.ZodError, filePath?: string) {
  const message = filePath
    ? `${context} in ${filePath}:\n${z.prettifyError(zodError)}`
    : `${context}:\n${z.prettifyError(zodError)}`;
  const hints: ErrorHint[] = filePath
    ? [{ message: `Fix the schema/data structure errors in ${filePath}` }]
    : [{ message: "Fix the schema/data structure errors above" }];
  super(message, { hints });
}

Additional context:

• CLI versions: 0.0.32
• Platforms: macOS (both Intel and ARM), Windows
• Internal vs external: 6 of 46 occurrences from internal users
• Common validation errors: missing required fields, invalid RLS configurations

Expected behavior: Entity files should validate successfully
Actual behavior: High volume of schema validation failures suggesting documentation or tooling gaps

---

Issue 5: Missing Build Output Directory

Error code: FILE_NOT_FOUND | Occurrences: 19 | Users affected: 13
Command: deploy | Type: System
Recurring: No | Existing issue: None
PostHog: View in error tracking

Error from PostHog:

FileNotFoundError: Output directory does not exist: C:\Users\<redacted>\한국축산기술포털\dist. Make sure to build your project first.

Stack trace (from PostHog, abbreviated):

FileNotFoundError: Output directory does not exist: C:\Users\<redacted>\...
    at runCLI (src/cli/index.ts:32:4)

What happened:
Users are attempting to deploy sites before building them, resulting in missing output directories.

Root cause in code:
Site deployment checks for the output directory existence before proceeding:

// src/core/site/deploy.ts:14-22
if (!(await pathExists(siteOutputDir))) {
  throw new FileNotFoundError(
    `Output directory does not exist: ${siteOutputDir}. Make sure to build your project first.`,
    {
      hints: [
        { message: "Run your build command (e.g., 'npm run build') first" },
      ],
    },
  );
}

Additional context:

• CLI versions: 0.0.32
• Platforms: Windows (x64), macOS, Linux
• Internal vs external: 5 of 19 occurrences from internal users
• Related to issue [Feature]: Build on deploy #167 (Feature: Build on deploy)

Expected behavior: Users build their projects before deploying or CLI guides them to build
Actual behavior: Users attempt to deploy without building first

---

Suggestions

1. Add function deployment timeout handling (critical): Add client-side timeout configuration and better retry logic for function deployments in src/core/resources/function/api.ts. Consider progressive timeout increases or chunked deployments for large functions.

2. Investigate authentication timeout root cause (high): Add detailed logging to authentication flows to identify where timeouts occur. Consider implementing exponential backoff for auth retries.

3. Improve project detection UX (medium): Add a global flag like --help-find-project or improve error messages with suggestions for nearby directories that contain Base44 projects.

4. Add entity validation assistance (medium): Consider adding a base44 entities validate command or better error messaging with examples for common RLS and schema patterns.

5. Implement auto-build detection (low): Related to existing issue [Feature]: Build on deploy #167, consider detecting common build patterns and offering to run builds automatically before deployment.