Skip to content

rutvej/errorfixit

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

AI-Powered Error Insight & Auto-Fix Dashboard

Overview

This project is an open-source minimal example of a full-stack architecture that:

  • Collects application error logs (via API)
  • Uses an LLM to analyze and suggest reasons for the error
  • Displays results in a dashboard
  • Allows the user to trigger a fix flow (options: generate prompt for IDE, auto-create PR, or copy-paste fix)
  • Supports background job processing (worker queue)
  • Includes a database for storing errors and resolutions

Architecture

  1. Backend (Go)

    • REST API to receive logs and serve dashboard data
    • Integration with LLM API (local Ollama / OpenAI / etc.)
    • Stores logs and resolutions in PostgreSQL
    • Publishes "deep analysis" tasks to a worker queue (Redis + BullMQ or Go workers)
  2. Worker

    • Background process (Go) that consumes tasks from the queue
    • Runs deeper LLM analysis
    • Optionally triggers auto-fix flow
  3. Frontend (React)

    • Minimal dashboard: list logs, show analysis, buttons for fix flow
    • Connects to backend API
    • Can be served by backend or run separately
  4. Database

    • PostgreSQL schema:
      • errors table (id, message, stacktrace, status, resolution)
      • tasks table (id, type, payload, status)
  5. LLM Integration

    • Local: Ollama (e.g., llama3)
    • Remote: OpenAI API (optional)

Setup

AI-Powered Error Insight & Auto-Fix Dashboard

This repo is a runnable, local development example that shows how to collect error logs, run LLM-powered analysis, and display results in a small React dashboard. It is intentionally opinionated for local/dev use only.

Quick checklist before publishing

  • Ensure no secrets are committed (check .env, *.pem, *.key, or other credential files)
  • Add any secrets to a secure secret manager (Vault, GitHub Secrets, or CI secrets) before pushing
  • Keep .env in .gitignore (this repo already ignores .env)
  • Rotate/set strong passwords and API keys for production (do not use defaults)

Architecture (short)

  • Backend: Go (Gin) — receives logs, enqueues jobs, can perform synchronous analysis
  • Worker: Go — BRPOP worker that runs deeper analysis and writes resolution back to DB
  • Frontend: React + Vite — dashboard to view logs and trigger fixes
  • Queue / Storage: Redis (queue), PostgreSQL (persistence)
  • LLM: Local Ollama (recommended for on-prem dev) with optional OpenAI fallback

Local setup (fast)

  1. Copy or create a .env locally (do not commit it). Example (.env is ignored by the repo):
# Database
POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_DB=errorfix

# Redis
REDIS_ADDR=redis:6379

# Backend
BACKEND_PORT=8090

# LLM (optional)
OPENAI_API_KEY=
OLLAMA_URL=http://ollama:11434
OLLAMA_MODEL=llama2
  1. Start services with Docker Compose:
docker-compose up -d --build
  1. Wait for services to be healthy. If using Ollama, pull the model inside the Ollama container:
docker-compose exec ollama ollama pull ${OLLAMA_MODEL:-llama2}
  1. Run the smoke test (basic end-to-end):
./scripts/smoke.sh

Simple curl examples

Create a log (POST /log):

curl -sS -X POST "http://localhost:8090/log" \
   -H "Content-Type: application/json" \
   -d '{"message":"Example error from curl","stacktrace":"main.go:123\nother.go:45"}'

List logs (GET /logs):

curl -sS "http://localhost:8090/logs"

Get a single log (example id 1):

curl -sS "http://localhost:8090/logs/1"

Security & secrets guidance (before you push to public git)

  • Do not commit .env or real credentials. This repo defaults to weak local credentials (postgres/postgres) for convenience — rotate before production.
  • If you already committed secrets, rotate them immediately and remove them from git history (use git filter-repo or GitHub's secret scanning tools). See next steps below.
  • Use CI/CD secrets (GitHub Actions secrets, GitLab variables) or an external secret manager for production credentials and API keys.

Git integration (recommended steps)

  1. Initialize a repo and add a remote (if not already):
git init
git add .
git commit -m "initial commit"
git remote add origin git@github.com:<your-org>/<your-repo>.git
git push -u origin main
  1. Protect secrets: ensure .env is in .gitignore (already present). If you have an accidental secret commit, do not push; instead remove it from history and rotate keys.

  2. Add CI to run tests/lint on push (GitHub Actions example): create a workflow that builds your backend and worker and runs basic smoke tests.

Jira integration (next steps / ideas)

  • Use the worker to create a Jira ticket when a log is marked analyzed (proposal):
    • Add a small Jira client in the worker that uses Jira REST API and creates an issue with summary, stacktrace, and suggested resolution.
    • Store the Jira API token in environment/secret manager, not in repo.
    • Optionally add a config file to map projects/issue types for your org.

Minimal approach (concept): in worker/processJob after analysis succeed, call a function like createJiraIssue(cfg, log) that POSTs to https://your-domain.atlassian.net/rest/api/3/issue with basic fields.

What I checked for secrets

  • .env present but contains only local defaults; OPENAI_API_KEY is empty.
  • .gitignore includes .env (good).
  • No *.pem, *.key, id_rsa, or obvious long API tokens were found in source files.

If you want, I can run a stricter secret scan (regex + entropy checks) before you push.

Next recommended tasks

  1. Add a small readiness gate for Ollama before enqueuing jobs (worker/backends retry exist but gating is deterministic).
  2. Add CI workflow that builds images and runs ./scripts/smoke.sh and fails on regressions.
  3. Add a Jira plugin (worker side) or webhook to create issues for analyzed errors.
  4. Add logging and monitoring: expose /metrics and use Prometheus + Grafana for observability.
  5. Create a CONTRIBUTING.md and SECURITY.md with publishing instructions and responsible disclosure process.

How I verified safety

  • Confirmed .env is ignored and contains no live API keys in the repository.
  • Searched common token names (API_KEY, PASSWORD, PRIVATE KEY, etc.) and found only local defaults.

Files changed

  • Readme.md — improved docs, curl examples, security guidance, and next steps.

If you want, I can also:

  • Add a pre-push git hook that prevents committing .env or large files.
  • Add a GitHub Actions workflow for builds + smoke tests.
  • Implement the Jira create-issue example in the worker (needs Jira API token provided via secrets).

Tell me which of the suggested items you want me to implement next and I will apply the changes.

Optional: enable local git hooks

This repo includes a simple pre-push hook at .githooks/pre-push that blocks pushing a tracked .env file and large files (>5MB). To enable the hook locally:

# from repo root
git config core.hooksPath .githooks

Once enabled, the hook runs on local pushes.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages