The AutoRepairService v2: What We Learned from 10,000 Build Failures
The AutoRepairService is one of Deployxa's most popular features, and it has handled millions of build failures since its launch. But the v1 service had limitations: it only handled missing npm packages, it was slow (sometimes taking 30 seconds to classify an error), and it occasionally misclassified errors (e.g., identifying a syntax error as a missing package). To improve the service, we analyzed 10,000 build failures from production deployments, identified the most common patterns, and built AutoRepairService v2. Here is what we learned, what changed in v2, and what is coming next.
The direct answer is that AutoRepairService v2 is a significant upgrade over v1, with three key improvements: broader coverage (v2 handles missing npm packages, missing Python packages, peer dependency conflicts, and version mismatches, vs. v1's npm-only coverage), faster classification (v2 uses a cached regex-first approach with Gemini 2.5 Flash as a fallback, vs. v1's Gemini-first approach), and higher accuracy (v2's regex patterns are hand-tuned from the 10,000 failure analysis, vs. v1's generic patterns). For more on the v1 architecture, see our article on the autonomous build self-healing engine.
What We Learned from 10,000 Build Failures
We analyzed 10,000 build failures from production deployments and identified the following patterns:
1. Missing npm packages (45 percent of failures)
The most common failure type, accounting for 45 percent of all build failures. The error message is typically Module not found: Error: Can't resolve 'clsx' (Webpack/Vite) or Cannot find module 'clsx' (Node.js). The fix is to install the missing package. The most commonly missing packages are: clsx, lucide-react, @radix-ui/react-slot, tailwind-merge, framer-motion, zod, react-hook-form, @tanstack/react-query.
2. Missing Python packages (15 percent of failures)
The second most common failure type, accounting for 15 percent. The error message is typically ModuleNotFoundError: No module named 'fastapi' or ImportError: cannot import name 'X' from 'Y'. The fix is to add the missing package to requirements.txt or pyproject.toml and run pip install.
3. Peer dependency conflicts (12 percent of failures)
The third most common failure type, accounting for 12 percent. The error message is typically ERESOLVE unable to resolve dependency tree (npm) or ResolutionImpossible (pip). The fix is to use --legacy-peer-deps (npm) or to update the conflicting packages to compatible versions.
4. Version mismatches (10 percent of failures)
The fourth most common failure type, accounting for 10 percent. The error message is typically TypeError: X is not a function (runtime) or Property 'X' does not exist on type 'Y' (TypeScript). The fix is to update the package to a compatible version.
5. Syntax errors (8 percent of failures)
The fifth most common failure type, accounting for 8 percent. The error message is typically SyntaxError: Unexpected token (JavaScript) or IndentationError: expected an indented block (Python). The fix is to fix the syntax error in the code.
6. Missing environment variables (5 percent of failures)
The sixth most common failure type, accounting for 5 percent. The error message is typically Error: DATABASE_URL is not set or PrismaClientInitializationError: Environment variable not found. The fix is to set the missing environment variable.
7. Other (5 percent of failures)
The remaining 5 percent includes a long tail of less common failures: Docker build errors, network errors, disk space errors, etc.
What Changed in v2
Based on the analysis, we made three key changes in AutoRepairService v2:
1. Broader coverage
v1 only handled missing npm packages (45 percent of failures). v2 handles missing npm packages (45 percent), missing Python packages (15 percent), peer dependency conflicts (12 percent), and version mismatches (10 percent), which covers 82 percent of all build failures (vs. v1's 45 percent).
2. Faster classification
v1 used Gemini 2.5 Flash first, with a regex fallback. This was slow (2 to 5 seconds per classification) and expensive (Gemini API calls cost money). v2 uses a regex-first approach, with Gemini 2.5 Flash as a fallback. The regex patterns are hand-tuned from the 10,000 failure analysis, which means they match 90 percent of failures instantly (under 100 milliseconds). Gemini is only called for the 10 percent of failures that the regex does not match, which is faster and cheaper.
3. Higher accuracy
v1's regex patterns were generic and occasionally misclassified errors (e.g., identifying a syntax error as a missing package). v2's regex patterns are hand-tuned from the 10,000 failure analysis, which means they are more specific and accurate. The misclassification rate dropped from 5 percent (v1) to under 1 percent (v2).
Step-by-Step: How v2 Processes a Build Failure
Here is how v2 processes a typical build failure.
Step 1: The build fails
The build runs npm run build, which fails with:
Module not found: Error: Can't resolve 'clsx' in '/app/src/components'Step 2: The regex classifier runs first
v2 runs the regex patterns against the error message. The pattern Module not found: Error: Can't resolve '([^']+)' matches, extracting clsx as the missing package. This takes under 100 milliseconds.
Step 3: The patcher runs
The patcher adds clsx to package.json and runs npm install to update the lockfile.
Step 4: The retry orchestrator runs
The orchestrator re-runs npm run build. This time, the build succeeds.
Step 5: The deployment proceeds
The build output is deployed to a container, the container starts, and the app is live. The developer sees a banner: "Build failed due to missing clsx. Auto-installed clsx and resumed deployment. Build succeeded on attempt 2."
Step 6: If the regex does not match, Gemini runs
If the regex patterns do not match (e.g., for a novel error type), v2 calls Gemini 2.5 Flash to classify the error. This takes 2 to 5 seconds, but it only happens for 10 percent of failures.
Common Pitfalls and Troubleshooting
The first pitfall is over-reliance on regex. Regex patterns are fast but brittle: a small change in the error message format can break the pattern. The fix is to have a comprehensive test suite that verifies the patterns against real error messages, and to update the patterns as build tools evolve. The second pitfall is Gemini API outages. If Gemini is unavailable (API outage, rate limit), v2 falls back to the regex patterns, which means 10 percent of failures (the ones the regex does not match) are not classified. The fix is to have a fallback classification (e.g., "unknown error, please check the build log") that surfaces the raw error to the developer. The third pitfall is false positives. The regex patterns might match an error that is not actually a missing package, which causes the patcher to install an unnecessary package. The fix is to verify the fix (re-run the build and check if it succeeds) before accepting the patch. The fourth pitfall is security. The patcher modifies package.json and runs npm install, which means it executes the package's install scripts. A malicious package could use the install script to run arbitrary code. The fix is to run npm install --ignore-scripts during the repair, which prevents install scripts from running. The fifth pitfall is cost. v2 is cheaper than v1 (because it uses regex first and Gemini only as a fallback), but it still makes Gemini API calls for 10 percent of failures. The fix is to cache Gemini classifications for common error patterns, which reduces the number of API calls.
What Is Coming Next
We are working on several improvements for AutoRepairService v3. First, Python repair: v2 handles missing Python packages, but v3 will also handle Python-specific errors (e.g., ImportError, AttributeError) by analyzing the error and proposing a fix. Second, Go repair: v3 will handle Go build errors (e.g., missing modules, type mismatches) by analyzing the error and proposing a fix. Third, proactive repair: v2 reacts to build failures, but v3 will proactively scan the repository for potential issues (e.g., imports that are not in package.json) before the build runs, which prevents the failure entirely. Fourth, repair persistence: v2 applies repairs to the build context but not to the source repository, which means the same issue can recur on the next build. v3 will offer to automatically create a pull request with the repair, so the fix is persisted to the source repository. Fifth, repair sharing: if multiple apps have the same missing dependency, v3 will learn from previous repairs and apply the fix proactively. For more on the AutoRepairService, see our article on the autonomous build self-healing engine. For more on the heuristic advisor, see our article on translating build errors into plain English.
Advanced AutoRepair Patterns
Beyond the basics, AutoRepairService benefits from several advanced patterns. The first is repair persistence. v2 applies repairs to the build context but not to the source repository, which means the same issue can recur on the next build. The fix is to offer to automatically create a pull request with the repair, so the fix is persisted to the source repository. The second is repair sharing. If multiple apps have the same missing dependency, v3 will learn from previous repairs and apply the fix proactively. The third is repair verification. v2 verifies the fix by re-running the build, but it does not verify that the fix is correct (e.g., that the added package is the right version). The fix is to check the package's compatibility with the project's other dependencies before applying the fix. The fourth is repair auditing. v2 logs the repairs it applies, but the logs are not easily searchable. The fix is to integrate the repair logs with the audit log (via the MCP server), so developers can see what repairs were applied and when. The fifth is repair customization. v2 applies repairs automatically, but some teams might want to review repairs before they are applied. The fix is to add a "review before apply" mode, where repairs are proposed but not applied until a developer approves them. For more on AutoRepair, see our articles on the autonomous build self-healing engine and the heuristic advisor.
When AutoRepair Is Not the Right Choice
AutoRepair is not always the right choice. For teams with strict dependency management (e.g., teams that review every dependency change), AutoRepair's automatic package installation is undesirable, because it bypasses the review process. The fix is to disable AutoRepair for those teams (via the app settings) and to surface build failures without attempting a repair. For teams that want to understand the root cause of every build failure (e.g., for learning purposes), AutoRepair's automatic fix masks the root cause. The fix is to review the repair log to understand what was fixed and why. For teams that are concerned about security (e.g., teams that do not want to install packages automatically), AutoRepair's automatic package installation is a risk. The fix is to review the added packages before accepting the repair. For more on build management, see our articles on the auto-detection engine and static analysis without execution.
Conclusion: Learning from Data Makes the Service Better
AutoRepairService v2 is a significant upgrade over v1, with broader coverage, faster classification, and higher accuracy. The improvements are based on the analysis of 10,000 real build failures, which means they address the actual problems developers face. By learning from data, we can make the service better over time, which means fewer failed builds and more shipped apps. For more on Deployxa's engineering, see our articles on the auto-detection engine and static analysis without execution. Learn about how we handle SSL at scale and the cost optimization engine in our companion articles. Explore our free developer tools to speed up your workflow. Try Deployxa Drop for an instant live preview with zero signup.