4a49bb458e
Simplify execution health check logic: - If executor responds (2xx or 4xx), tool is HEALTHY - Only mark BROKEN for 5xx errors or network/timeout failures - Validation errors (URL format, missing fields) mean tool IS working - Remove brittle pattern matching for specific error messages The previous approach tried to match specific error patterns to determine if an error was "acceptable". This was fragile. The new approach: - Import check: can we load and describe the tool? - Execution check: did the tool execute at all? If a tool throws a validation error, it executed successfully - it's correctly rejecting invalid test input. Only infrastructure failures (executor down, network timeout) indicate a truly broken tool. |
||
|---|---|---|
| .. | ||
| src | ||
| .gitignore | ||
| eslint.config.mjs | ||
| next-env.d.ts | ||
| next.config.ts | ||
| package.json | ||
| postcss.config.js | ||
| tailwind.config.ts | ||
| tsconfig.json | ||
| vercel.json | ||