fix(tools): add Atlassian error extractor to all Jira, JSM, and Confluence tools

[waleedlatif1]

Summary

• Wires up the existing atlassian-errors error extractor to all 95 Atlassian tool configs (25 Jira, 24 JSM, 46 Confluence) so the executor surfaces meaningful error messages instead of generic "Request failed with status X"
• Fixes the atlassian-errors extractor itself to handle all three Atlassian error response formats: errorMessage (JSM), errorMessages array (Jira), and message (Confluence)

Test plan

• Trigger an error on a Jira tool (e.g., retrieve non-existent issue) and verify the error message contains the actual Atlassian error text
• Trigger an error on a JSM tool and verify meaningful error message
• Trigger an error on a Confluence tool and verify meaningful error message
• Verify happy-path execution is unaffected (errorExtractor only runs on error responses)

[vercel]

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

[cursor]

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-apps]

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

Filename	Overview
apps/sim/tools/error-extractors.ts	Extractor enhanced with RFC 7807 errors-array and field-level errors-object branches; the RFC 7807 branch silently drops errors with detail but no title, and the data.error wrapper produced by internal proxy routes still isn't handled.
apps/sim/tools/jsm/create_request.ts	Adds errorExtractor: 'atlassian-errors'; routes through /api/tools/jsm/request which wraps failures as { error: "JSM API error: …" } — a field the atlassian-errors extractor does not check.
apps/sim/tools/jira/retrieve.ts	Adds errorExtractor: 'atlassian-errors'; calls Atlassian APIs directly, so the extractor correctly sees raw Atlassian error payloads.
apps/sim/tools/confluence/search.ts	Adds errorExtractor: 'atlassian-errors'; routes through /api/tools/confluence/search which returns { error: errorMessage } on failure — not matched by the atlassian-errors extractor.
apps/sim/tools/confluence/retrieve.ts	Mechanical addition of errorExtractor: 'atlassian-errors'; no other changes.

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

Loading

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

[greptile-apps]

atlassian-errors extractor is bypassed for all internal-route tools

All 24 JSM tools route through /api/tools/jsm/.... When the Atlassian API call fails, these routes extract the Atlassian message and return it wrapped as { error: "JSM API error: <message>" } (see route.ts:parseJsmErrorMessage). The atlassian-errors extractor only checks errorMessage, errorMessages[], and message — none of which is error — so it returns undefined and the executor surfaces "Request failed with status X".

Before this PR, the absence of errorExtractor caused the executor to try all extractors in fallback order. The nested-error-object extractor matched data.error and correctly returned the human-readable string. This PR's deterministic mode skips all fallbacks, so meaningful error text is now silently dropped.

The same regression affects Confluence tools that use /api/tools/confluence/... routes (e.g., search/route.ts:70 returns { error: errorMessage }), and Jira tools write.ts, update.ts, and add_attachment.ts.

The fix needs to either: (a) update internal API routes to forward the Atlassian error body unchanged instead of re-wrapping it, (b) use a composite extractor that also checks data.error, or (c) omit errorExtractor on the internal-route tools to restore fallback behavior.

[greptile-apps]

Use ErrorExtractorId constant for type safety

All 95 Atlassian tool files use the string literal 'atlassian-errors' rather than the ErrorExtractorId.ATLASSIAN_ERRORS constant exported from this file. Other integrations (e.g., Telegram tools) consistently use ErrorExtractorId.TELEGRAM_DESCRIPTION. A typo in a string literal would silently fall back to the generic "Request failed with status X" message, whereas the constant provides compile-time safety.

[greptile-apps]

RFC 7807 errors array silently drops detail when title is absent

If errors is a non-empty array but the first entry carries detail without a title (permissible under RFC 7807, which makes title optional), the inner if (err?.title) block is skipped without returning. Because errors IS an array, the field-level object check (!Array.isArray) is also skipped, so the extractor falls through to data.message and ultimately returns undefined. The detail text is silently lost and the executor surfaces "Request failed with status X" instead.

Suggested change

	if (Array.isArray(errorInfo?.data?.errors) && errorInfo.data.errors.length > 0) {
	const err = errorInfo.data.errors[0]
	if (err?.title) {
	return err.detail ? `${err.title}: ${err.detail}` : err.title
	}
	}
	if (Array.isArray(errorInfo?.data?.errors) && errorInfo.data.errors.length > 0) {
	const err = errorInfo.data.errors[0]
	if (err?.title) {
	return err.detail ? `${err.title}: ${err.detail}` : err.title
	}
	if (err?.detail) {
	return err.detail
	}
	}