home / skills / project-n-e-k-o / n.e.k.o / tts-error-reporting

tts-error-reporting skill

/.agent/skills/tts-error-reporting

This skill ensures TTS worker errors are reported to the main process to trigger user-friendly toasts and prevent silent failures.

npx playbooks add skill project-n-e-k-o/n.e.k.o --skill tts-error-reporting

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: tts-error-reporting
description: Convention for reporting errors from multiprocessing TTS workers to the main process frontend. Use this skill when modifying, adding, or debugging TTS workers in tts_client.py to ensure connection errors, quotas, and API limits correctly display Toast notifications to the user rather than failing silently.
---

# TTS Error Reporting Protocol

To ensure users are properly notified when a TTS service encounters an error (such as quota exhaustion, API issues, or connection failures), TTS workers running in separate processes must propagate errors back to the main process (`core.py`).

## Core Rule: Use `response_queue.put(("__error__", error_msg))`

When a TTS worker (e.g. `step_realtime_tts_worker`, `qwen_realtime_tts_worker`, etc.) catches an error, it **MUST NOT** only log the error using `logger.error()`. It **MUST ALSO** send the error message back to the main process through its `response_queue` using the explicit tuple format `("__error__", error_msg)`.

This ensures that `core.py`'s `tts_response_handler` can intercept the error and translate it into a frontend WebSocket message (`type: 'status'`), triggering a user-friendly Toast notification (e.g., "💥 免费TTS限额已耗尽").

### Example Implementation

```python
# Bad Pattern (Fails silently for user)
except Exception as e:
    logger.error(f"TTS Worker Error: {e}")
    # Worker dies or hangs, user stuck on "Preparing..."

# Good Pattern (Structured JSON error for i18n frontend toasts)
import json
except Exception as e:
    logger.error(f"TTS Worker Error: {e}")
    # Map to specific error codes known to i18n
    error_payload = json.dumps({"code": "API_QUOTA_TIME", "details": str(e)})
    response_queue.put(("__error__", error_payload))

# Acceptable Fallback (Fallback 1008 error if code unknown)
except Exception as e:
    logger.error(f"TTS Worker Error: {e}")
    error_payload = json.dumps({"code": "API_1008_FALLBACK", "msg": str(e)})
    response_queue.put(("__error__", error_payload))
```

### WebSocket Stream Callbacks Example

```python
import json
def on_error(self, message: str): 
    logger.error(f"TTS Error: {message}")
    error_payload = json.dumps({"code": "API_1008_FALLBACK", "msg": message})
    self.response_queue.put(("__error__", error_payload))
```

## Checklist for Adding a New TTS Worker

Whenever you add a new TTS API worker in `tts_client.py`:
1. Ensure the worker signature accepts a `response_queue`.
2. Locate all network initialization blocks, `try/except` loops, and `on_error` WebSocket callbacks.
3. In every local exception block where the worker might fail or drop the connection, add `response_queue.put(("__error__", error_message_string))`.
4. Ensure string encoding handles JSON cleanly if propagating raw API errors.

Overview

This skill defines a convention for reporting errors from multiprocessing TTS workers back to the main process so frontend users receive Toast notifications instead of silent failures. It targets TTS workers in tts_client.py and prescribes a strict response_queue tuple format for error propagation. Use it to make connection errors, quota limits, and API faults visible and actionable in the UI.

How this skill works

TTS workers catch exceptions and send a structured error payload to the main process via response_queue.put(("__error__", error_msg)). core.py's tts_response_handler listens for that tuple, converts it into a WebSocket status message, and the frontend displays a localized Toast alert. Workers should embed JSON error objects (code + details) when possible so the frontend can map to i18n messages.

When to use it

  • When adding a new TTS worker function in tts_client.js/python that runs in a separate process.
  • When handling network errors, connection drops, or WebSocket on_error callbacks inside a worker.
  • When an API returns quota, rate-limit, or auth errors that should show to the user.
  • When debugging silent TTS hangs where the UI remains stuck on a ‘Preparing…’ state.
  • When converting raw provider errors into standardized frontend-friendly messages.

Best practices

  • Always accept a response_queue parameter in worker signatures and use it on all exception paths.
  • Send a tuple exactly as ("__error__", error_payload_string) to ensure tts_response_handler recognizes it.
  • Prefer JSON payloads with a code and details, e.g. {"code":"API_QUOTA_TIME","details":"..."}, for i18n mapping.
  • Log the original exception locally, then also push a sanitized error string to the response queue.
  • Provide a fallback code (e.g. API_1008_FALLBACK) if the error type cannot be mapped to a known code.

Example use cases

  • Wrap WebSocket on_error callback to json.dumps({code:'API_1008_FALLBACK',msg:message}) and put to response_queue.
  • Catch provider-specific quota exceptions and send {code:'API_QUOTA_TIME',details:err} so the UI shows a quota Toast.
  • During initialization failures send an immediate __error__ message to avoid leaving the UI in a loading state.
  • Add response_queue notifications in retry loops so final failures surface instead of silent worker death.

FAQ

What exact tuple should a worker send for errors?

Send response_queue.put(("__error__", error_message_string)) where error_message_string is preferably a JSON string with code and details.

Can I log the error and not send it to the queue?

No — logging alone can leave users stuck. Always push an __error__ tuple so the frontend can display a user-visible Toast.