Does lost jobs result in a post back to the webhook?
#Failed webhook jobs
frank marten
grave parcelBOT
Hi @frank marten. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
prisma urchinBOT
Hey there! This channel allows you to ask Kapa.ai for assistance. But it looks like you haven't connected your Discord profile to your Deepgram account yet. You can do so at https://community.deepgram.com - by doing so, you'll be able to ask questions in #1115960287183511643 if you need human assistance!
grave parcelBOT
Based on the knowledge sources provided, I can answer your question about failed webhook jobs and lost jobs in Deepgram.
When a job is marked as "Lost" in Deepgram, it typically means that the metadata about the response could not be retrieved. According to the Deepgram API Discussions, requests can go through a flow of Pending -> Unknown -> Lost. This usually occurs when there's an issue with retrieving metadata about the request.
Regarding whether lost jobs result in a post back to the webhook, the knowledge sources don't provide explicit information about this specific scenario. However, we can infer some relevant information:
-
For successful transcriptions using callbacks, Deepgram will POST the results to the provided callback URL, as mentioned in the Deepgram Documentation.
-
If the HTTP status code of the response to the callback POST request is unsuccessful (not 200-299), Deepgram will retry the callback up to 10 times with a 30-second delay between attempts.
-
For lost jobs, the documentation states: "You won't be charged for this request. If you see this occur repeatedly please contact Deepgram support."
Given this information, it's not explicitly stated whether lost jobs result in a post back to the webhook. The system seems designed to handle successful transcriptions and retry unsuccessful callback attempts, but it's unclear how it behaves with lost jobs.
To get a definitive answer, you may need to contact Deepgram support directly, as the provided knowledge sources don't contain enough information to conclusively answer whether lost jobs trigger a webhook post back.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
frank marten
@grave parcel Is it safe to assume a job not reported back within 20 minutes to be stale?
grave parcelBOT
Let me check the knowledge base for you again. One moment! :books:
Based on the knowledge sources provided, I can offer some insights regarding your question about job timeouts in Deepgram.
While there isn't explicit information about a general "staleness" threshold for all jobs, we can infer some relevant details about timeouts:
-
For non-Whisper models, Deepgram has a timeout window of 10 minutes for STT (Speech-to-Text) requests.
-
For Whisper models, the timeout window is extended to 20 minutes.
This information is stated in the Deepgram Help Center FAQ:
"Deepgram's timeout window for STT request is 10 minutes for all non-Whisper models, and 20 minutes for Whisper models. You should set your HTTP request timeout to either 10 or 20 minutes, depending on the model you use."
Given this information, it would be reasonable to consider a job that hasn't reported back within 20 minutes as potentially stale, especially if you're using a Whisper model. However, it's important to note that this is a maximum processing time rather than a guaranteed completion time.
For more accurate handling of job statuses, it would be best to implement proper error handling and use callbacks when possible. If you're consistently experiencing issues with jobs not reporting back, it may be worth contacting Deepgram support for more specific guidance related to your use case.
Remember that these timeout windows are for processing time, and additional factors like network latency or callback retries (if using webhooks) might affect the total time before you receive a response.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
frank marten
@grave parcel The timeout window of 20 minutes mentioned seems to be referring to requests without a callback/webhook. What is the timeout window for jobs using webhook?
grave parcelBOT
Let me check the knowledge base for you again. One moment! :books:
You're right to point out the distinction between requests with and without callbacks/webhooks. Let me clarify the timeout windows for jobs using webhooks based on the information provided in the knowledge sources.
The 20-minute timeout window mentioned earlier indeed refers to synchronous requests without callbacks. For asynchronous requests using webhooks, the timeout behavior is different.
According to the Deepgram Documentation on Using Callbacks, when you use a callback URL in your request to Deepgram's API:
- Deepgram will immediately respond with a
request_id. - The audio is then processed asynchronously.
- The transcript is returned to your server through the callback URL you provided.
Importantly, the documentation states:
"If the HTTP status code of the response to the callback POST request is unsuccessful (not 200-299), Deepgram will retry the callback up to 10 times with a 30 second delay between attempts."
This means that for webhook-based jobs, Deepgram will attempt to deliver the results for up to approximately 5 minutes after the transcription is complete (10 retries * 30 seconds = 300 seconds or 5 minutes).
However, the knowledge sources don't provide a specific overall timeout window for the entire process when using webhooks. It's possible that the initial processing time limits (10 minutes for non-Whisper models, 20 minutes for Whisper models) still apply, but this isn't explicitly stated for webhook-based jobs.
Given the lack of specific information about a timeout window for webhook jobs, it would be best to contact Deepgram support for a definitive answer on this matter. They would be able to provide you with the most accurate and up-to-date information about timeout windows for webhook-based jobs.
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
frank marten
@grave parcel Is there any documentation or example of the payload of a failed job? How can we simulate a failed job?
grave parcelBOT
Let me check the knowledge base for you again. One moment! :books:
Based on the knowledge sources provided, I can offer some information about error responses in Deepgram, but I don't have specific documentation on the payload of a failed job or how to simulate one. Let me share what I can find that's relevant to your question.
Deepgram provides documentation on API error responses, which might be helpful in understanding how errors are communicated. According to the Deepgram Documentation:
For information on Deepgram's error messages and error codes, read the API Reference Errors page.
The Errors page in the API Reference provides examples of error responses for various scenarios. While these are specifically for Text-to-Speech errors, they give an idea of the structure of error responses. Here's an example of an error response:
{
"err_code": "Bad Request",
"err_msg": "Bad Request: No such model/version combination found.",
"request_id": "[unique_request_id]"
}
However, it's important to note that these examples are for synchronous API calls and may not directly represent the payload of a failed job in an asynchronous webhook scenario.
Regarding simulating a failed job, the knowledge sources don't provide specific information on how to do this. However, based on the error examples, you might be able to simulate some error conditions by:
- Using an invalid model name
- Providing malformed input
- Using unsupported audio formats or configurations