Recommendation for amplification of openai.transcripts.create behavior in documentation, or alternative implementation

[mflorence99]

When create() is called with the default options (ie: { poll: true ... }) it will not return until either:

1. The transcription completes
2. The transcription errors
3. Neither of the above occur within pollingTimeout ms (default: 180,000 ms or 3 minutes)

As a consequence, if the transcription takes longer than pollingTimeout then the API will throw an error, but the transcription will proceed to completion on the AssemblyAI infrastructure, and the account will be billed for a transcription that cannot be retrieved.

Client code has these not-so-desirable options:

1. Use the { poll: false } and hand-code polling itself
2. Pass { pollingTimeout: Number.MAX_VALUE } (but lose the ability to detect a real timeout)
3. Try to estimate the duration of the transcription and pass that

Alternatively, could the code be changed to accept { pollingTimeout: -1 } or make that the default, and not timeout? Should the concept of 'timeout' be more properly applied to the low-level fetch code in services/base.ts?

Currently, 'timeout' just means that the transcription is taking 'too long', and the user doesn't have any real knowledge of what 'too long' means.

Many thanks for your consideration of this issue.

[Swimburger]

I'll bring up the feedback with our team and let you know what we decide, but for now here are my initial thoughts.

• We should set the polling timeout to -1 by default.
• We should handle the polling timeout -1 value as you propose.
• The concept of a global fetch timeout would be useful for any API SDK, but it would be separate from the polling timeout I think.
• We could expose the polling function publicly so users can create, get the ID, and then start polling.
• We could add the transcript object inside the polling timeout error.

[mflorence99]

Many thanks @Swimburger -- re exposing the polling function:

What would be super-useful during a poll is to receive some indication of % complete. This is what Google's Speech-to-text API does and why we manually coded our own poll loop, so we can drive a progress bar.

I understand this is an enhancement request that goes beyond the issue I raised, but I thought I'd put it out there.

[Swimburger]

@mflorence99 I think that's a great idea, but it's not something the SDK can help with unless it's included in the API/product.
So I'll submit this as a user request.
For now, creating your own loop would be the best way to go to create your own progress bar.

[Swimburger]

@mflorence99 We'd love to learn more about your use case for a progress bar. Can we talk about that via email?
You can email me at ***.

[Swimburger]

In 3.1.0, we changed the default to be an infinite timeout, or no timeout, and added a new function client.transcripts.waitUntilReady(...) in case you want to create the transcript first without polling, and then poll.