Sentry Issues

HyperTTS Sentry issues

HyperTTS reports crashes to Sentry. Use the mcp__sentry__* tools — never WebFetch a sentry.io URL, the rendered page is behind auth and returns nothing useful.

This skill is read-only. Reading from Sentry — searching, fetching issues and events, running Seer analysis — is always fine and needs no confirmation. Do not make any call that changes state in Sentry: no resolving, ignoring, assigning, commenting, or bulk-updating issues. Triage decisions are the user's to make in the Sentry UI. See "Read-only boundary" below.

Project coordinates (hard-coded — never look them up)

The DSN in hypertts_addon/__init__.py:154 ends in /6170140 — that trailing number is the project ID. Do not call find_organizations or find_projects to rediscover this.

Other projects in the same org (cloud-language-tools, anki-language-tools, anki-vocabai, vocabai-app, …) are different products. Unless the user explicitly names one, every query in this repo is scoped to 6170140.

Looking up a specific issue

The user usually gives a short ID (ANKI-HYPER-TTS-KT8) or a full URL. Pass it straight through:

mcp__sentry__get_sentry_resource(url='https://language-tools.sentry.io/issues/ANKI-HYPER-TTS-KT8/')
mcp__sentry__get_sentry_resource(resourceType='issue', organizationSlug='language-tools', resourceId='ANKI-HYPER-TTS-KT8')

That returns the latest event: stack trace, tags, and contexts. Read the tags — they carry most of the triage signal (see the tag reference below).

For root-cause analysis with suggested code fixes, mcp__sentry__analyze_issue_with_seer takes 2–5 minutes. Only run it when the user asks for it or when the stack trace alone isn't enough.

Searching for issues

mcp__sentry__search_issues(
    organizationSlug='language-tools',
    projectSlugOrId='6170140',
    query='is:unresolved',
    period='24h',        # 24h | 7d | 14d | 30d | 90d
    sort='freq',         # date | freq | new | user | recommended
    limit=100)

Useful queries:

Gotcha — boolean tag values: the MCP's embedded query-rewriter lowercases boolean tag values (is_audio_request_exception:true) when the query uses a -24h-style window, and the lowercase form matches nothing. Write lastSeen:-1d / firstSeen:-7d instead of -24h, or use the period parameter, when the query also filters on a boolean tag.

For counts and aggregations (how many events, which service fails most) use mcp__sentry__search_events with dataset='errors', not search_issues:

mcp__sentry__search_events(
    organizationSlug='language-tools', projectSlug='anki-hyper-tts',
    dataset='errors', query='is:unresolved',
    fields=['audio_service', 'count()'], sort='-count()', period='7d')

Tag reference — what HyperTTS attaches

Global, on every event (hypertts_addon/__init__.py:167):

• anki_version, hypertts_pro_user, release (anki-hyper-tts@<version>), environment (production / qa / development), user.id (the config user_uuid)

On audio-request failures, set in servicemanager.py:318 and :368 — this is the only place audio exceptions are captured:

• is_audio_request_exception: True — scopes a search to TTS failures
• audio_service — which service raised it; maps to hypertts_addon/services/service_<x>.py
• exception_type — the exception class name, from hypertts_addon/errors.py
• error_retryable — the retryable flag on the exception
• hypertts_pro — request went through VocabAI/CLT rather than direct
• audio_request_reason, final_attempt

Contexts on the same events: audio_voice (name, voice_key, service), audio_options, audio_request (the source text), audio_request_context (reason, batch_uuid, retry_count).

Issues are fingerprinted as ['{{ default }}', voice.service], so the same exception from two services becomes two separate issues.

Other capture sites: anki_utils.py:75 (configuration anomalies — ConfigurationAnomaly, with the hypertts_configuration context), anki_utils.py:414/422 (unknown exceptions surfaced to the user), and logging_utils.py:75 (logger-based events).