This builds on this PR https://github.com/deepgram/deepgram-python-sdk/pull/365. We shouldn't be deleting the signal exit event because this can cause a race condition. This should be set once and on connect, this event should be cleared. This is to support client reuse. This matches functionality in the .NET and Go SDK.
Tested on examples, edge cases, and expected failures unit tests.
Types of changes
What types of changes does your code introduce to the community Python SDK?
Put an x in the boxes that apply
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update or tests (if none of the other choices apply)
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.
Proposed changes
This builds on this PR https://github.com/deepgram/deepgram-python-sdk/pull/365. We shouldn't be deleting the signal exit event because this can cause a race condition. This should be set once and on connect, this event should be cleared. This is to support client reuse. This matches functionality in the .NET and Go SDK.
Tested on examples, edge cases, and expected failures unit tests.
Types of changes
What types of changes does your code introduce to the community Python SDK? Put an
x
in the boxes that applyChecklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.Further comments
NA