Conversation
|
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| elif msg_type == "error": | ||
| logger.error("xAI STT error: %s", data.get("message", "unknown error")) | ||
| error_msg = data.get("message", "unknown error") | ||
| logger.error("xAI STT error: %s", error_msg) |
There was a problem hiding this comment.
🟥 Provider errors leak into log bodies
An xAI-controlled error_msg enters the log body without a PII marker. Provider errors can contain customer content that collectors cannot redact.
Was this helpful? React with 👍 or 👎 to provide feedback.
| error_msg = data.get("message", "unknown error") | ||
| logger.error("xAI STT error: %s", error_msg) | ||
| raise APIStatusError( | ||
| message=f"xAI STT error: {error_msg}", |
There was a problem hiding this comment.
🟥 Provider errors leak through exceptions
The new APIStatusError embeds xAI-controlled error_msg. Exception logs and telemetry can expose customer content without a redactable PII attribute.
Was this helpful? React with 👍 or 👎 to provide feedback.
2 participants
Problem
When the xAI STT WebSocket receives a server-side error message (e.g.
{"type": "error", "message": "ASR stream timed out"}), the plugin logs the error butrecv_taskcontinues waiting for more messages. xAI sends no further events after this error — the stream is effectively dead, and transcription silently stops for the rest of the session.Fix
Raise
APIStatusErroron"error"type messages so the exception propagates throughrecv_task→tasks_group→ the existingwhile Truereconnect loop in_run(), which opens a fresh WebSocket and resumes transcription.This is consistent with how the plugin already handles unexpected connection closures (line 374).