Pattern Matching: The Never Ending Story

Summary

When a "Cannot read property of undefined" error hits your API, Cazon matches it against a curated library covering thousands of common React, JavaScript, TypeScript, and build tool errors. You get instant context: what causes this, common fixes, severity, and whether it's a rookie mistake or a framework bug. Pattern matching runs before AI analysis, providing instant feedback like Stack Overflow patterns as code.

---

Most production errors aren't unique. That TypeError: Cannot read property 'user' of undefined you're debugging right now? Your team has probably seen it before. So has the JavaScript community at large. The error message is generic, but the root cause and fix are usually one of three or four common patterns.

This is where pattern matching comes in. Instead of treating every error as a novel problem requiring fresh investigation, we match errors against a library of known patterns and provide instant context about what's likely wrong and how to fix it.

The Error Pattern Library

Cazon maintains a growing library of error patterns covering common issues across React, JavaScript, TypeScript, Node.js, Next.js, and popular build tools. These patterns are organized into categories:

Syntax Errors - Missing semicolons, unclosed brackets, typos in variable names. Usually caught by linters or TypeScript, but occasionally slip through.

Runtime Errors - Null reference errors, type mismatches, undefined function calls. The most common production errors, accounting for 60% of JavaScript exceptions.

Logic Errors - Off-by-one errors, incorrect conditionals, race conditions. Harder to detect automatically, but patterns emerge when teams track historical fixes.

Dependency Errors - Missing modules, version conflicts, broken imports. Often caused by deployment issues or package manager problems.

Security Errors - CORS violations, authentication failures, permission errors. Not always bugs, sometimes intentional security boundaries being hit.

Each pattern in the library includes:

• Match criteria: Regular expressions or fuzzy matching rules for the error message and stack trace
• Root cause description: Plain English explanation of what this error typically means
• Common fixes: Code examples or configuration changes that usually resolve this
• Severity level: Is this a critical production bug or a minor annoyance?
• Framework context: Does this only happen in specific frameworks or versions?

Pattern Structure: Error as Data

Here's what a pattern looks like (simplified for clarity):

{
  "id": "js-null-property",
  "name": "Cannot read property of undefined",
  "match": {
    "errorType": "TypeError",
    "messagePattern": "Cannot read propert(y|ies) '.*' of (undefined|null)"
  },
  "rootCause": "Attempting to access a property on an object that is null or undefined. Usually caused by missing null checks or asynchronous timing issues.",
  "commonFixes": [
    "Add null check: if (obj && obj.user) { ... }",
    "Use optional chaining: obj?.user?.name",
    "Check async timing: ensure data is loaded before accessing"
  ],
  "severity": "medium",
  "frameworks": ["any"],
  "exampleStackTrace": "at processUser (user.js:42:5)"
}

When an error arrives, we run it through all patterns in the library. If the error type matches and the message matches the regex, we attach the pattern metadata to the error. Now instead of just seeing "TypeError: Cannot read property 'user' of undefined", developers see:

• What this means: Attempting to access a property on an undefined object
• Common cause: Missing null check or async timing issue
• How to fix: Use optional chaining or add null checks
• Severity: Medium (not critical, but should be fixed)

Why Patterns Run First: Speed and Cost

Pattern matching happens before AI analysis, and there's a good reason for this: speed and cost. Matching an error against our pattern library takes under 10ms and costs nothing (it's regex matching against a static library). Sending an error to an AI model for analysis takes 500-2000ms and costs API quota.

For common errors where we have high-confidence patterns, there's no need to invoke AI. We can provide instant context from the pattern library, saving both time and AI credits. AI analysis is reserved for novel errors that don't match any known patterns, or when developers explicitly request deeper analysis.

This creates a fallback chain:

1. Pattern match (10ms, free, covers 60% of errors)
2. AI analysis (1000ms, uses quota, covers 30% of errors)
3. Basic context (0ms, free, minimal info for the remaining 10%)

Most teams hit the pattern library for routine errors and only invoke AI for truly novel problems. This makes error intelligence fast and cost-effective at scale.

Open Pattern Library (Like ESLint Rules)

The error pattern library is designed to be open and extensible, similar to ESLint rules or TypeScript type definitions. We're building toward a model where teams can contribute patterns, with curated contributions to ensure quality and accuracy.

Why open source this? Because your team has seen errors we haven't. If you're using a niche framework or custom library, you're encountering errors specific to that ecosystem. By making the pattern format open, teams will eventually be able to contribute those patterns back, helping other teams using the same tools.

Contributing a pattern will be simple:

1. Define the match criteria (error type, message pattern, stack trace hints)
2. Document the root cause and common fixes
3. Submit via pull request or API
4. We validate it against a test suite of known errors
5. If it passes, it goes live for all Cazon users

Over time, the library will become more comprehensive, covering not just mainstream frameworks but also domain-specific tools and custom error classes. This is how we'll scale beyond our curated patterns; the community will add the long tail.

Real Examples from the Library

Let's look at a few patterns in action:

Pattern: EADDRINUSE (Port Already in Use)

• Message: listen EADDRINUSE: address already in use :::3000
• Root cause: Another process is already listening on port 3000
• Common fixes: Kill the existing process (lsof -i :3000), change port number, ensure previous server instance shut down cleanly
• Severity: Low (development annoyance, rarely hits production)

Pattern: Module Not Found

• Message: Cannot find module 'express'
• Root cause: Dependency missing from node_modules, usually due to incomplete npm install or gitignored node_modules
• Common fixes: Run npm install, check package.json for missing dependency, ensure build process includes install step
• Severity: Medium (breaks app startup)

Pattern: Unhandled Promise Rejection

• Message: UnhandledPromiseRejectionWarning: Unhandled promise rejection
• Root cause: Async function threw an error that wasn't caught with try/catch or .catch()
• Common fixes: Wrap async code in try/catch, add .catch() to promise chains, use top-level error handler
• Severity: High (can crash Node process in future versions)

Pattern: CORS Error

• Message: Access to fetch at '...' from origin '...' has been blocked by CORS policy
• Root cause: Backend didn't set correct CORS headers, or request includes credentials without allowing them
• Common fixes: Set Access-Control-Allow-Origin header, configure Express CORS middleware, enable credentials if needed
• Severity: Medium (blocks legitimate requests, but not a code bug)

Each of these patterns appears hundreds of times per day across the JavaScript ecosystem. By matching them instantly, we save developers from Googling the same error message for the 47th time.

How Teams Add Custom Patterns

Beyond the community library, teams can define custom patterns for internal errors. If your app has domain-specific error codes (ERR_PAYMENT_TIMEOUT, ERR_INVENTORY_MISMATCH), you can create patterns that explain what those mean to new team members or AI assistants.

Custom patterns are private to your organization and follow the same structure as community patterns:

{
  "id": "internal-payment-timeout",
  "name": "Payment Gateway Timeout",
  "match": {
    "errorCode": "ERR_PAYMENT_TIMEOUT",
    "messagePattern": "Stripe.*timeout"
  },
  "rootCause": "Stripe API took longer than 30s to respond. Usually caused by Stripe downtime or network issues between us and Stripe.",
  "commonFixes": [
    "Check Stripe status page",
    "Retry payment with exponential backoff",
    "Check our network connection to Stripe API"
  ],
  "severity": "high",
  "teamContact": "@payments-team"
}

Now when a payment timeout occurs, every developer (and AI assistant) immediately knows this is a Stripe connectivity issue, knows the standard fixes, and knows to contact the payments team if it persists. Custom patterns encode tribal knowledge as data.

What This Means for Debugging Speed

With pattern matching in place, routine errors get resolved in seconds instead of minutes. The developer doesn't need to remember what "EADDRINUSE" means or Google "Cannot read property of undefined" yet again. The AI assistant doesn't need to generate a generic explanation based on the error message alone. The pattern library provides instant, accurate context.

For novel errors, we still invoke AI analysis, but now it's focused on genuinely unusual problems rather than wasting cycles on errors we've seen a thousand times. This combination of fast pattern matching plus intelligent AI fallback gives you the best of both worlds: speed for common errors, depth for rare ones.

What's Next

Pattern matching gives you instant recognition of known errors, but what about errors you've never seen before? How do you know if a new error affects 5 users or 500 users? How do you prioritize when multiple errors occur simultaneously?

Next, we'll explore impact scoring: how Cazon uses machine learning to analyze error frequency, affected users, and business context to assign priority scores automatically. This is where Error Intelligence goes beyond patterns and starts learning your organization's specific priorities.

---

This is Post 5 of our launch series on error intelligence. Follow along as we unpack the problem, introduce solutions, and show you how Cazon is building the missing intelligence layer between production errors and AI coding assistants.

Next: Post 6 - ML Impact Scoring →