Sentry Audio Error Review

Sentry Audio-Error Categorization Review

Pull every unresolved HyperTTS audio-request issue from the last 24 hours, judge whether each issue's exception_type tag matches the actual error evidence, and report any that look mis-categorized so the service code can be fixed.

Every audio-request exception is captured at hypertts_addon/servicemanager.py:232-246 with the tag is_audio_request_exception: True. The exception class name is captured in the exception_type tag and the retryable flag in error_retryable. When a service maps an HTTP response or network failure to the wrong subclass of ServiceRequestError, retry logic and triage signal both degrade — that is what this skill catches.

Sentry coordinates (hard-coded)

• Organization slug: language-tools
• Project ID: 6170140
• Sentry filter: is:unresolved is_audio_request_exception:True, last 24h
• Canonical issue URL form: https://language-tools.sentry.io/issues/<shortId>/

Step 1 — Pull the issue list

Call mcp__sentry__search_issues with:

• organizationSlug='language-tools'
• projectSlugOrId='6170140'
• query='is:unresolved is_audio_request_exception:True lastSeen:-1d'
• limit=100

The is_audio_request_exception:True tag filter is required — it scopes the search to audio request failures only (the same filter used in the Sentry UI URL for this triage workflow).

Use lastSeen:-1d, not lastSeen:-24h. The two are semantically equivalent, but the embedded query-rewriter in the Sentry MCP normalizes the boolean tag value to lowercase (is_audio_request_exception:true) only on the -24h path, and the lowercase form returns zero results for this tag. The -1d form is preserved verbatim and works.

Record each issue's shortId, title, and Sentry URL. If zero issues are returned, report "No unresolved audio-request issues in the last 24 hours" and stop.

Step 2 — Gather evidence for each issue

For each issue, call mcp__sentry__get_sentry_resource with the issue URL. From the latest event extract:

• exception_type tag — the current categorization
• error_retryable tag — the current retryable flag
• audio_service tag — which service raised it
• The exception class name and message in the stack trace
• Any HTTP status code, underlying exception type, or low-level error string referenced in the message (e.g. 502 Bad Gateway, requests.exceptions.ConnectionError, Connection refused, ReadTimeout, Name or service not known)

If an issue's tags or event payload don't contain enough evidence to judge the categorization, note it as "insufficient evidence" rather than flagging it.

Step 3 — Apply the categorization rules

Use this table — derived from hypertts_addon/errors.py and the mapping logic in hypertts_addon/cloudlanguagetools.py and hypertts_addon/servicemanager.py — to judge whether exception_type matches the evidence:

Mis-categorization heuristic — flag an issue when any of these hold:

• The evidence clearly matches a specific row above but exception_type is the catch-all UnknownServiceError or the legacy RequestError. A more specific class would have improved retry logic and grouping.
• A permanent error (rows where Retryable=False) is currently tagged with a transient class, or vice versa — compare the table's Retryable column against the error_retryable tag.
• The evidence points to a different specific row than exception_type claims (e.g. tagged ServiceTimeoutError but the trace shows a 502 response).