The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 9, 2026 10:15pm

PR Summary

Medium Risk
Touches a large number of Atlassian tool configs and changes shared error-message parsing, so failures will surface different messages and any mismatch in extractor logic could mask useful details.

Overview
Improves Atlassian tool error reporting. All Jira, JSM, and Confluence tool configs now specify errorExtractor: 'atlassian-errors' so executor failures surface API-provided messages instead of generic HTTP status errors.

Expands atlassian-errors parsing. The extractor now falls back across Atlassian’s common error shapes (errorMessage, errorMessages[], and message) and joins multiple errorMessages into a single string.

^{Reviewed by Cursor Bugbot for commit 4a1a84e. Configure here.}

Greptile Summary

This PR wires errorExtractor: 'atlassian-errors' to all 95 Atlassian tool configs and enhances the extractor to cover RFC 7807 errors arrays (Confluence v2) and Jira field-level errors objects, in addition to the pre-existing errorMessage, errorMessages[], and message formats.

The improvements to the extractor logic are correct for tools that call Atlassian APIs directly. For tools routed through internal Next.js proxy handlers (/api/tools/jsm/…, /api/tools/confluence/…), those handlers wrap failures as { error: \"…\" } — a field the atlassian-errors extractor does not match — so meaningful error text is still dropped in those paths (noted in prior review threads).

Confidence Score: 4/5

Safe to merge for direct-API Atlassian tools; the extractor bypass for proxy-routed tools (JSM, most Confluence) is an unresolved P1 from prior review threads that means those paths still surface generic status-code errors.

All new findings from this review are P2. However, two P1 findings from prior review threads remain unaddressed: the atlassian-errors extractor does not match the data.error wrapper format returned by internal proxy routes for JSM and Confluence tools, meaning those tools regress compared to the previous fallback-chain behaviour. Score is 4 rather than 5 to reflect that pre-existing P1 concern.

apps/sim/tools/error-extractors.ts — RFC 7807 detail-without-title fallthrough; also see prior thread on data.error proxy format not being matched.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Tool Request Fails] --> B{Has errorExtractor?}
    B -->|Yes: atlassian-errors| C{Direct Atlassian API?}
    B -->|No| D[Try all extractors in order]
    C -->|Yes - Jira retrieve etc.| E[Raw Atlassian error body]
    C -->|No - via /api/tools/jsm or /api/tools/confluence| F[Proxy wraps as data.error string]
    E --> G{Check errorMessage}
    G -->|found| H[Return errorMessage]
    G -->|not found| I{Check errorMessages array}
    I -->|found| J[Return joined messages]
    I -->|not found| K{Check errors array - RFC 7807}
    K -->|found with title| L[Return title: detail]
    K -->|found, no title but has detail| M[⚠️ Silent fallthrough - no return]
    K -->|not found| N{Check errors object - field-level}
    N -->|found| O[Return field: msg pairs]
    N -->|not found| P{Check message}
    P -->|found| Q[Return message]
    P -->|not found| R[Return 'Request failed with status X']
    F --> S{atlassian-errors checks data.error?}
    S -->|No - not handled| R
    M --> P

_{Reviews (1): Last reviewed commit: "fix(tools): handle all Atlassian error f..." | Re-trigger Greptile}