home / skills / project-n-e-k-o / n.e.k.o / 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-reportingReview the files below or copy the command above to add this skill to your agents.
---
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.
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.
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.
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.