-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Summary
Critical authentication timeout bug persists for 11+ consecutive days requiring immediate fix. The unclassified authentication timeout remains the highest-impact error, affecting 56 users across 39 occurrences.
| Metric | Value |
|---|---|
| Time range | last 24 hours |
| Total errors | 186 |
| CLI bugs | 2 |
| Backend issues | 3 |
| User errors (working as designed) | 6 |
| Unique users affected | 116 |
| Internal user occurrences | 57 |
Errors requiring action
1. Authentication timeout lacks error classification — CLI bug
| Error code | None (unclassified) |
| Occurrences | 39 (1 internal) |
| Users affected | 39 |
| Command | deploy |
| Platforms | Linux, Windows, Darwin |
| PostHog | View in error tracking |
| Existing issue | Referenced in #426, #423, #416, #415, #414 |
| Recurring | Yes (11+ days) |
Error: (from PostHog — the actual error message users see)
Error: Authentication timed out. Please try again.
Stack trace: (only showing frames from packages/cli/src/)
at waitForAuthentication (packages/cli/src/cli/commands/auth/login-flow.ts:71)
at login (packages/cli/src/cli/commands/auth/login-flow.ts:105)
Root cause: The authentication timeout throws a generic Error without proper classification:
// packages/cli/src/cli/commands/auth/login-flow.ts:69-74
} catch (error) {
if (error instanceof Error && error.message.includes("timed out")) {
throw new Error("Authentication timed out. Please try again.");
}
throw error;
}This timeout occurs when the OAuth2 device code expires (line 60: timeout: expiresIn * 1000). The generic Error lacks proper classification for telemetry tracking, causing error_code: null and is_user_error: null in PostHog.
Suggested fix: In packages/cli/src/cli/commands/auth/login-flow.ts:71, replace throw new Error("Authentication timed out. Please try again.") with throw new AuthExpiredError("Authentication timed out. Please try again.") using the existing error class from packages/cli/src/core/errors.ts:147.
2. Site deploy directory validation inconsistency — CLI bug
| Error code | FILE_NOT_FOUND vs INVALID_INPUT |
| Occurrences | 2 (2 internal) |
| Users affected | 1 |
| Command | site deploy |
| Platforms | Darwin |
| PostHog | View in error tracking |
| Existing issue | None |
| Recurring | No |
Error: (from PostHog — the actual error message users see)
FileNotFoundError: Output directory does not exist: /Users/<redacted>/docs/plans/ClimbClaw/site/dist. Make sure to build your project first.
Stack trace: (limited frames available in PostHog data)
at runCLI (packages/cli/src/cli/index.ts:33)
Root cause: The site deployment logic should consistently throw InvalidInputError when the output directory doesn't exist:
// packages/cli/src/core/site/deploy.ts:14-23
if (!(await pathExists(siteOutputDir))) {
throw new InvalidInputError(
`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" },
],
},
);
}However, some code path is throwing FileNotFoundError instead, causing inconsistent error classification.
Suggested fix: Audit all site deploy code paths to ensure consistent use of InvalidInputError for missing output directories, or investigate if FileNotFoundError is being thrown by a different validation layer.
Backend issues (not CLI fixes)
Brief table of errors caused by the backend/server, not the CLI:
| Error | Occurrences | Users | Command | PostHog |
|---|---|---|---|---|
| Network connection timeout (fetch failed) | 16 | 16 | whoami |
View in error tracking |
| Entity tool validation (non-existent entity 'Task') | 15 | 11 | deploy |
View in error tracking |
| OAuth token expiration | 3 | 3 | deploy |
View in error tracking |
| Entity schema deletion blocked (existing records) | 3 | 3 | deploy |
View in error tracking |
| App not found (404 errors) | 4 | 4 | exec, functions list |
Various PostHog links |
These represent backend/server issues where the CLI correctly reports the error response.
User errors (working as designed)
Brief table of expected user errors where the CLI validation is correct:
| Error | Occurrences | Users | Command | PostHog |
|---|---|---|---|---|
| No Base44 project found (CONFIG_NOT_FOUND) | 34 | 21 | link, dashboard open |
View in error tracking |
| Non-interactive mode validation (INVALID_INPUT) | 27 | 15 | deploy, link, eject |
Various links |
| Project already linked (CONFIG_EXISTS) | 10 | 6 | link |
View in error tracking |
| App configuration missing (CONFIG_INVALID) | 8 | 6 | functions deploy, site deploy |
Various links |
| Invalid configuration schema (SCHEMA_INVALID) | 7 | 6 | deploy, functions deploy |
Various links |
All user errors provide appropriate validation messages and guidance. The non-interactive mode validation errors suggest users (especially CI/CD systems) are running commands without required flags.
Recurring errors
| Error | Days recurring | Existing issue | Tracked? |
|---|---|---|---|
| Authentication timeout (unclassified) | 11+ days | Referenced in #426, #423, #416, #415, #414 | No dedicated issue |
The authentication timeout classification bug has appeared in every daily error report since at least 2026-03-08 but remains unfixed, continuing to affect user experience and telemetry accuracy.
Action items
Numbered list of concrete next steps, most important first:
-
[critical]
packages/cli/src/cli/commands/auth/login-flow.ts:71— Replacethrow new Error("Authentication timed out. Please try again.")withthrow new AuthExpiredError("Authentication timed out. Please try again.")to enable proper telemetry classification. TheAuthExpiredErrorclass is already defined inpackages/cli/src/core/errors.ts:147and extendsUserErrorwith error code "AUTH_EXPIRED" and appropriate hints. -
[medium]
packages/cli/src/core/site/deploy.ts— Investigate site deploy error classification inconsistency. Ensure all missing output directory validations consistently throwInvalidInputErrorrather thanFileNotFoundErrorto maintain proper error categorization. -
[low] Monitor backend entity validation errors — while not CLI bugs, the volume of entity tool reference errors (15 occurrences) suggests users may need better validation or guidance when referencing entities in agent configurations.