Error Occurs When Retrieving Usage Information Due to Delay in Data Availability

[Viamo]

What is the current behavior?

When calling deepgram.listen.prerecorded.v('1').transcribe_file(payload, options) followed immediately by deepgram.manage.v('1').get_usage_request(DEEPGRAM_PROJECT_ID, requestId), an error occurs in the file client.py at line 1004. The variable result has a value of None.

Steps to reproduce

1. Call deepgram.listen.prerecorded.v('1').transcribe_file(payload, options).
2. Immediately call deepgram.manage.v('1').get_usage_request(DEEPGRAM_PROJECT_ID, requestId) with DEEPGRAM_PROJECT_ID and requestId.

Expected behavior

The get_usage_request function should return valid usage information without returning None, and the package should handle the error if the data is not available yet.

Please tell us about your environment

• Operating System/Version: Windows 10
• Python Version: v3.11

Other information

The issue appears to be related to the delay in retrieving usage information. Even if the information is unavailable, the error should still be handled properly by the package.

[davidvonthenen]

I looked into this, and it is an API issue. I will forward it to engineering, as the API should return an error instead of a result.

In the meantime, I would recommend checking for the null value in the result to determine data availability if you have a need for the API that quickly; otherwise, will need to wait for this fix in the API.

[Viamo]

The variable result is not accessible because it is inside the package. The only way is to give up on the SDK and access the API directly, but for now, I just added sleep().

[davidvonthenen]

The variable result is not accessible because it is inside the package. The only way is to give up on the SDK and access the API directly, but for now, I just added sleep().

Let me take a look at this and see what I can do.

[Viamo]

Thank you for the help. I'm using sleep(), and that’s sufficient for now. It would be great if you could address the errors at your end. Thanks!

[davidvonthenen]

Will be available in the 3.7.0 that is building right now.

[Viamo]

It appears that the error is still occurring because, in the file client.py, on line 1002, the variable result receives a value that may be None, and on line 1006, the operation UsageRequest.from_json(result) throws an error.
I propose adding a None check to ensure that the variable result is properly validated before passing it to UsageRequest.from_json(result).

deepgram-sdk, version: 3.7.3

[davidvonthenen]

We just need to mark the field Optional which will set it to None. Will make that change. I also think you mean response not result, correct?
https://github.com/deepgram/deepgram-python-sdk/blob/main/deepgram/clients/manage/v1/response.py#L489

[Viamo]

No, I mean result in line 1002. I conducted some investigations and found that sometimes the result has a value of 'null', which causes an error when calling res = UsageRequest.from_json('null').

[Viamo]

And one more bug:

Sometimes usage.response is null in code:
usage = deepgram.manage.v('1').get_usage_request(DEEPGRAM_PROJECT_ID, request_id)

Screenshot for for i in range(10):

There is a difference in the third iteration with the same request.

[davidvonthenen]

ahhhh I see. My misunderstanding on where the error is. That sounds reasonable. thanks for your help with this!!

[davidvonthenen]

There is a PR open for this. A data availability exception will be thrown now:

• Async: https://github.com/deepgram/deepgram-python-sdk/pull/472/files#diff-409e993c659f805875acecd5f70fc36ddb73ce8b3fbe0bb514882df2a1551fc2R234-R237
• Threaded: https://github.com/deepgram/deepgram-python-sdk/pull/472/files#diff-3fd4f97ff30988310dc483371a310a0eb391e685a5343c24334f625eeebea858R230-R233

[Viamo]

Why might the data be unavailable? Is it possible to ensure the data is always available (availability exception is still necessary to implement)? In third-party APIs, usage is returned immediately in the results of the first API call, without requiring a second API call to retrieve usage, which is why their data is always available.