Closed dvonthenen closed 8 months ago
@coderabbitai review
[!WARNING]
Rate Limit Exceeded
@dvonthenen has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 21 minutes and 7 seconds before requesting another review.
How to resolve this issue?
After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. We recommend that you space out your commits to avoid hitting the rate limit.How do rate limits work?
CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information.Commits
Files that changed from the base of the PR and between e735bfa96c7d18a7a6b9773a0fefba09efb7490a and 71588bc63657c77660342c4c00b9de161edc47bc.
The recent updates encompass changes to the overall Deepgram project, focusing on metadata adjustments in the Deepgram.csproj
file and a bug fix in the HttpClientUtil.cs
file within the Utilities
namespace related to timeout settings.
File Path | Change Summary |
---|---|
Deepgram/Deepgram.csproj |
Updated metadata: PackageId , Title , added Version , Authors ; removed Company information. |
.../Utilities/HttpClientUtil.cs |
Implemented a bug fix in SetTimeOut method to adjust timeout value handling in HttpClient logic. |
Deepgram.Tests/UtilitiesTests/HttpClientUtilTests.cs |
Added namespaces: System , Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection . Added ExecuteAsync_NotExecutedWithinTimeout_ThrowsExecptionAsync method for testing timeout scenarios. |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Ok. So I have done a ton of analysis on this issue. The analysis here is correct but also has a ton of other consequences: https://github.com/deepgram/deepgram-dotnet-sdk/issues/127#issuecomment-1779085524
Immediate problems - as the above analysis points out, we can't re-create the client because all of the clients have pointers to the initial httpclient created when the clients were initialized. we need to remove the creation of the client in order to set the timeout of the original clients. this also means that the timeout value is shared among all clients
things to note - a single HttpClientUtil()
object is not thread-safe; consequently neither is DeepgramClient
. Setting the timeout value to multiple different values in multiple threads based on need (for example, uploading a large file) might inadvertently increase the timeouts for other requests. The same is true for smaller values... you might inadvertently (like for a simple get) decrease the timeout for operations needing more time in another thread. the take away, you must have a HttpClientUtil()
per thread. To be on the safest side while using timeouts, you need to consider using a timeout value that is a high watermark value for all operations in a single thread when using a single DeepgramClient
.
Calling an attempting to set the timeout multiple times (ie after the first initial GET/PUT/etc), will yield in an exception:
System.InvalidOperationException : This instance has already started one or more requests. Properties can only be modified before sending the first request.
Hence the need for the high watermark value (ie time for your longest operation) if a single DeepgramClient
is used in each thread.
This supersedes this PR: https://github.com/deepgram/deepgram-dotnet-sdk/pull/179
I would have used that PR but there were Project Properties that needed to be updated beyond what was provided.
NOTE: This is going on the
release-v3
branch and will tag a release from there.Summary by CodeRabbit
Summary by CodeRabbit
Chores
Bug Fixes