error-fixer

name

error-fixer

description

Fix JavaScript and HTTP errors flagged for AI in the admin dashboard. Queries the database for errors with ai_status='flagged_for_ai', analyzes them, and attempts to fix them. Use for: "fix errors"/"fix flagged errors", "check error queue", AI error-queue / AI-flagged errors, or after flagging errors in the admin dashboard. Triggers: "fix errors", "error queue", "ai errors", "flagged errors", "fix ai errors", "/fix-errors"

Error Fixer

Fetch and fix errors flagged for AI correction in the admin dashboard. Supports both JS errors (error_reports) and HTTP errors (http_error_logs).

Skill-specific learnings: See references/learnings.md for PostgreSQL error codes, RPC debugging patterns, and gotchas.

Cross-cutting learnings: See .claude/LEARNINGS.md for:

• "Supabase/Database" → RLS+GRANT 403 errors, RPC 404 patterns, CHECK constraint values
• "React/TypeScript" → useEffect infinite loops, null checks

Relation to the AI Index

This skill replaces the AI Index bootstrap for error-fix sessions — do not re-read Docs/ai-index/manifest.yml#bootstrap.on_error_fix_task when invoked. The patterns that list points at (silent_error_swallow_pattern, edge_fn_postgrest_error_masking, and the canonical fixes for both) already live in references/learnings.md here, where this skill loads them automatically.

The manifest is for sessions that start from a feature/domain question and have no skill match — it is the fallback orientation layer, not a parallel one.

Workflow

1. FETCH    → Get AI-flagged errors from both tables
2. TRIAGE   → Identify stale-cache / superseded reports BEFORE deep analysis
3. ANALYZE  → Understand each remaining error (stack trace, context, URL, status)
4. FIX      → Apply fixes using systematic debugging
5. MARK     → Mark errors as ai_fixed with notes
6. REPORT   → Summarize what was fixed
7. LEARN    → If non-obvious pattern discovered, invoke /opi to capture it

Step 2: Triage stale reports first (cheap dismissal)

A large share of JS reports come from a browser tab still running a pre-fix Vite bundle. Do this before opening any file:

1. Decode the bundle timestamp. Every Vite-served module URL in the stack trace has ?t=<ms> (e.g. VerseSetReader.tsx?t=1778490515075). That's Date.now() at the moment Vite last hot-reloaded the file.
2. Compare with last commit touching the file:

   git log -1 --format="%ci %h %s" -- <file/path/from/stack>
   

3. If the file was committed AFTER the bundle timestamp, the report is stale — mark ai_fixed with:

   Already fixed in commit <sha>. Report came from a browser tab still running
   pre-fix Vite bundle (t=<ms>). Hard reload clears it.
   

4. Also dismiss as stale: CHUNK_LOAD_ERROR "Importing a module script failed" on a route that recently changed (deploy-vs-cache race).

This collapses 3 identical reports of the same hooks/syntax error into a single 30-second triage instead of a full investigation.

Step 1: Fetch Flagged Errors

Query both error tables using Supabase MCP:

JS Errors:

SELECT id, error_type, error_message, stack_trace, context, user_action, ai_prompt, created_at
FROM error_reports WHERE ai_status = 'flagged_for_ai'

HTTP Errors:

SELECT id, method, url, status_code, response_body, request_context, navigation_path, ai_prompt, created_at
FROM http_error_logs WHERE ai_status = 'flagged_for_ai'

Or use RPC functions: get_errors_for_ai() and get_http_errors_for_ai().

Important: The ai_prompt field contains specific instructions from the admin.

Step 2: Analyze Each Error

JS Errors

1. Read the ai_prompt - Admin's instruction
2. Parse stack trace - File path, line number, call chain
3. Check context - route, action, other data
4. Read affected file(s)

HTTP Errors

1. Read the ai_prompt - Admin's instruction
2. Check URL and status code - What endpoint failed and why
3. Review response_body - Error message from server
4. Check navigation_path - User's journey to this error
5. Find the code - Locate fetch/API call that made this request

Step 4: Fix

Direct fix is the default. Only delegate to a sub-skill when the change is genuinely outside the scope of "edit code + apply migration + redeploy edge function" — e.g., complete RLS redesign, multi-week feature work. For the common case, just apply the fix here.

Common patterns for quick reference

Error Type	Common Fix
TypeError: Cannot read property 'x' of undefined	Add null checks, optional chaining
TypeError: x is not a function	Check imports; if auth.getClaims is not a function → pinned @supabase/supabase-js@2.49.1 doesn't expose it. Use auth.getUser(token).
Rendered more hooks than during the previous render	Hooks called after early return — move all hooks above early returns
ChunkLoadError / Failed to fetch dynamically imported module	Usually stale browser bundle after deploy — see Step 2 triage. If recurrent, check React.lazy imports.
Identifier 'X' has already been declared	Duplicate declaration — usually a hook destructuring shadowed by a later const X = …
400 + 23514 check_violation	Read RPC source via SELECT prosrc FROM pg_proc WHERE proname='X', find the failing INSERT/UPDATE. Also check sibling table constraints (e.g. practice.practices mirroring practice.practice_templates).
400 + 42703 undefined_column	Read actual table schema first. The column may be aggregated on-the-fly by an RPC (completed_days[] from user_reading_progress) rather than stored on the table.
400 + 42883 undefined_function	RPC calls non-existent function — check function name/args
400 + 42P13 "Final statement returns too many columns"	A public wrapper does SELECT * FROM bible_schema.X(...) but the inner RPC added columns. DROP+CREATE the wrapper with the new return shape.
400 Bad Request (other)	Validate request params; check payload format
403 + 42501 insufficient_privilege	Need all three: schema in PostgREST db-schemas, GRANT for authenticated, RLS policy for the operation

Migration drift check (PGRST202)

When a PGRST202 fires on <rpc_name>:

grep -rl "FUNCTION.*<rpc_name>" supabase/migrations/

If a migration file exists, the diagnosis is "local-only migration was never pushed to remote". Apply it via mcp__plugin_supabase_supabase__apply_migration and verify with pg_proc. No code change needed.

Public-wrapper review (after any bible_schema.X RPC change)

Many frontend calls go through public.X wrappers that do SELECT * FROM bible_schema.X(...). When the inner RPC's return shape changes, the wrapper's RETURNS TABLE(...) desyncs and emits 42P13. After modifying any bible_schema RPC:

SELECT n.nspname, p.proname
FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE p.proname = '<changed_rpc_name>'

If a public row appears, inspect its body — if it's a SELECT * wrapper, drop and recreate it with the new column list.

Step 4: Mark as Fixed

Use direct UPDATE for both tables (the mark_error_ai_fixed RPC requires admin role which MCP SQL lacks):

-- JS Errors
UPDATE error_reports SET ai_status = 'ai_fixed', ai_fixed_at = NOW(),
  ai_fix_notes = 'description' WHERE id = 'error-uuid'

-- HTTP Errors
UPDATE http_error_logs SET ai_status = 'ai_fixed', ai_fixed_at = NOW(),
  ai_fix_notes = 'description' WHERE id = 'error-uuid'

Good fix notes examples:

• "Added null check for user object in ProfileCard.tsx:45"
• "Fixed RLS policy for authenticated users on topics table"
• "Added missing CORS header to edge function"

Step 5: Report Summary

## Error Fix Summary

### JS Errors
#### Fixed (X)
- [error_type] in file.tsx:line - Brief description

#### Could Not Fix (X)
- [error_type] - Reason

### HTTP Errors
#### Fixed (X)
- [status_code] [method] /path - Brief description

#### Could Not Fix (X)
- [status_code] [method] /path - Reason

Step 6: Learn (invoke /opi)

After fixing errors, evaluate whether any fix revealed a non-obvious pattern worth capturing. Invoke the opi skill when:

• The root cause was surprising or non-obvious (e.g., table in wrong schema, MCP role limitations)
• The same mistake could easily happen again in new code
• A workaround was needed for a platform limitation
• The fix involved a multi-step diagnostic that future sessions should skip

How: Use the Skill tool to invoke opi with a summary of what was learned. The opi skill routes learnings to the right file (global LEARNINGS.md or skill-specific learnings.md).

Skip this step for straightforward fixes (typos, missing null checks, obvious import errors).

Database Schema Reference

-- error_reports (JS errors)
ai_status: 'pending' | 'flagged_for_ai' | 'ai_fixed' | 'verified'
ai_prompt: text
ai_fixed_at: timestamp
ai_fix_notes: text

-- http_error_logs (HTTP errors)
ai_status: 'pending' | 'flagged_for_ai' | 'ai_fixed' | 'verified'
ai_prompt: text
ai_fixed_at: timestamp
ai_fix_notes: text

-- RPC functions
get_errors_for_ai()              -- JS errors flagged for AI
get_http_errors_for_ai()         -- HTTP errors flagged for AI
mark_error_ai_fixed(p_id, p_fix_notes)       -- Mark JS error fixed
-- NOTE: No RPC for HTTP errors — use direct UPDATE on http_error_logs

Best Practices

1. Always read ai_prompt first - Admin may have specific instructions
2. Don't fix what you don't understand - Mark as "could not fix"
3. Run build after fixes - Verify no new errors
4. Write clear fix notes - Help admin understand what changed
5. Group related errors - Multiple errors may have same root cause
6. Check Edge Function logs - For HTTP 500 errors, use Supabase MCP get_logs
7. For 400 RPC errors, always read the RPC source first - SELECT prosrc FROM pg_proc WHERE proname = 'X'
8. After remote RPC fix, create local migration - supabase migration new <name>, write SQL, supabase migration repair <ts> --status applied
9. Parse the PostgreSQL error code from response_body — it tells you exactly what went wrong (see references/learnings.md for code reference)