Implement Channel Callback Interface #263
Conversation
WalkthroughThe changes encompass modifications to configuration files, client implementations, and various handler structures across the Deepgram SDK. Key adjustments include the introduction of new WebSocket and REST client functionalities, restructuring of callback and channel handling mechanisms, and updates to error messaging constants. These alterations collectively enhance the SDK's ability to manage real-time audio processing and transcription while improving code organization and maintainability. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant WSClient
participant DeepgramAPI
User->>+WSClient: Connect()
WSClient->>DeepgramAPI: Establish WebSocket Connection
DeepgramAPI-->>-WSClient: Connection Established
WSClient->>User: Connection Successful
User->>WSClient: Send Audio Data
WSClient->>DeepgramAPI: Transmit Audio
DeepgramAPI-->>WSClient: Transcription Results
WSClient->>User: Display Transcription
User->>WSClient: Disconnect()
WSClient->>DeepgramAPI: Close Connection
DeepgramAPI-->>WSClient: Connection Closed
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? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Outside diff range, codebase verification and nitpick comments (7)
examples/speech-to-text/websocket/microphone_channel/README.md (2)
3-3: Consider rephrasing for conciseness.The phrase "in order to" can be shortened to "to" for conciseness.
Apply this diff to improve the sentence:
-This example uses the Microphone as input in order to detect conversation insights in what is being said. +This example uses the Microphone as input to detect conversation insights in what is being said.Tools
LanguageTool
[style] ~3-~3: Consider a shorter alternative to avoid wordiness.
Context: ...is example uses the Microphone as input in order to detect conversation insights in what is...(IN_ORDER_TO_PREMIUM)
17-17: Consider rephrasing to avoid repetition.The phrase "makes use of" is repeated. Consider rephrasing to avoid wordiness.
Apply this diff to improve the sentence:
-The Live API (Real-Time) example makes use of a [microphone package](https://github.com/deepgram/deepgram-go-sdk/tree/main/pkg/audio/microphone) contained within the repository. That package makes use of the [PortAudio library](http://www.portaudio.com/) which is a cross-platform open source audio library. +The Live API (Real-Time) example uses a [microphone package](https://github.com/deepgram/deepgram-go-sdk/tree/main/pkg/audio/microphone) contained within the repository. This package utilizes the [PortAudio library](http://www.portaudio.com/), a cross-platform open-source audio library.Tools
LanguageTool
[style] ~17-~17: You have already used this phrasing in nearby sentences. Shortening it will avoid wordiness.
Context: ...ned within the repository. That package makes use of the [PortAudio library](http://www.port...(REP_MAKE_USE_OF)
[uncategorized] ~17-~17: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...rtaudio.com/) which is a cross-platform open source audio library. If you are on Linux, you...(EN_COMPOUND_ADJECTIVE_INTERNAL)
pkg/client/speak/v1/rest/client.go (1)
Line range hint
66-68: Reminder: Address the TODO comment.The TODO comment suggests detecting if the source is JSON and wrapping the text in a JSON object if not. Consider implementing this feature for improved functionality.
Would you like me to help implement this feature or open a GitHub issue to track this task?
pkg/client/common/v1/websocket.go (4)
213-344: Improve error categorization inlisten.Consider categorizing errors more explicitly to enhance error handling and logging.
425-462: Add comments to explain the logic incloseStream.Consider adding comments to explain the logic behind sending close messages and handling errors.
464-503: Simplify the switch statement innormalClosure.Consider simplifying the switch statement to improve readability.
515-546: Add comments to explain the logic incloseWs.Consider adding comments to explain the logic behind closing the WebSocket connection and handling cleanup.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (36)
- .golangci.yaml (2 hunks)
- examples/speech-to-text/websocket/http_callback/main.go (2 hunks)
- examples/speech-to-text/websocket/http_channel/main.go (1 hunks)
- examples/speech-to-text/websocket/microphone_callback/main.go (1 hunks)
- examples/speech-to-text/websocket/microphone_channel/README.md (1 hunks)
- examples/speech-to-text/websocket/microphone_channel/main.go (1 hunks)
- pkg/api/listen/v1/websocket/callback_default.go (9 hunks)
- pkg/api/listen/v1/websocket/callback_router.go (10 hunks)
- pkg/api/listen/v1/websocket/chan_default.go (1 hunks)
- pkg/api/listen/v1/websocket/chan_router.go (1 hunks)
- pkg/api/listen/v1/websocket/constants.go (1 hunks)
- pkg/api/listen/v1/websocket/interfaces/constants.go (1 hunks)
- pkg/api/listen/v1/websocket/interfaces/interfaces.go (1 hunks)
- pkg/api/listen/v1/websocket/types.go (1 hunks)
- pkg/api/manage/v1/manage.go (1 hunks)
- pkg/client/analyze/v1/client.go (1 hunks)
- pkg/client/analyze/v1/types.go (1 hunks)
- pkg/client/common/v1/constants.go (1 hunks)
- pkg/client/common/v1/interfaces/interfaces.go (1 hunks)
- pkg/client/common/v1/rest.go (3 hunks)
- pkg/client/common/v1/types.go (1 hunks)
- pkg/client/common/v1/websocket.go (1 hunks)
- pkg/client/listen/client.go (7 hunks)
- pkg/client/listen/v1/rest/client.go (1 hunks)
- pkg/client/listen/v1/rest/types.go (1 hunks)
- pkg/client/listen/v1/websocket/client_callback.go (1 hunks)
- pkg/client/listen/v1/websocket/client_channel.go (1 hunks)
- pkg/client/listen/v1/websocket/constants.go (3 hunks)
- pkg/client/listen/v1/websocket/new_using_callbacks.go (1 hunks)
- pkg/client/listen/v1/websocket/new_using_chan.go (1 hunks)
- pkg/client/listen/v1/websocket/types.go (1 hunks)
- pkg/client/live/legacy.go (2 hunks)
- pkg/client/manage/v1/client.go (1 hunks)
- pkg/client/manage/v1/types.go (1 hunks)
- pkg/client/speak/v1/rest/client.go (1 hunks)
- pkg/client/speak/v1/rest/types.go (1 hunks)
Files skipped from review due to trivial changes (1)
- pkg/client/listen/v1/websocket/constants.go
Additional context used
Learnings (1)
examples/speech-to-text/websocket/http_channel/main.go (2)
Learnt from: dvonthenen PR: deepgram/deepgram-go-sdk#258 File: examples/text-to-speech/websocket/interactive/main.go:35-43 Timestamp: 2024-08-22T03:05:19.486Z Learning: dvonthenen prefers to exclude example code from automated checks in the Deepgram Go SDK repository.Learnt from: dvonthenen PR: deepgram/deepgram-go-sdk#239 File: examples/speak/stream/http/main.go:45-65 Timestamp: 2024-06-19T14:40:12.485Z Learning: The code in `examples/speak/stream/http/main.go` is intended as a straightforward example to aid in understanding and driving the implementation, as per user dvonthenen's clarification.
LanguageTool
examples/speech-to-text/websocket/microphone_channel/README.md
[style] ~3-~3: Consider a shorter alternative to avoid wordiness.
Context: ...is example uses the Microphone as input in order to detect conversation insights in what is...(IN_ORDER_TO_PREMIUM)
[style] ~17-~17: You have already used this phrasing in nearby sentences. Shortening it will avoid wordiness.
Context: ...ned within the repository. That package makes use of the [PortAudio library](http://www.port...(REP_MAKE_USE_OF)
[uncategorized] ~17-~17: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...rtaudio.com/) which is a cross-platform open source audio library. If you are on Linux, you...(EN_COMPOUND_ADJECTIVE_INTERNAL)
Additional comments not posted (140)
pkg/client/speak/v1/rest/types.go (1)
13-13: Transition to RESTClient inClientstruct.The
Clientstruct now embeds*common.RESTClient, indicating a shift towards RESTful communication. Ensure that all methods and functionalities relying on the previous*common.Clientstructure are compatible with the new*common.RESTClient.Run the following script to verify the usage of
Clientstruct methods:pkg/client/analyze/v1/types.go (1)
13-13: Transition to RESTClient inClientstruct.The
Clientstruct now embeds*common.RESTClient, indicating a shift towards RESTful communication. Ensure that all methods and functionalities relying on the previous*common.Clientstructure are compatible with the new*common.RESTClient.Run the following script to verify the usage of
Clientstruct methods:Verification successful
Transition to RESTClient in
Clientstruct verified.The methods associated with the
Clientstruct, such asDoFile,DoStream,DoText,DoURL, andAPIRequest, align with RESTful operations, indicating compatibility with the new*common.RESTClient. No issues found with the transition.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all method calls on `Client` struct instances. # Test: Search for method calls on `Client` instances. Expect: Compatibility with `RESTClient`. rg --type go -A 5 $'Client'Length of output: 148039
pkg/client/listen/v1/rest/types.go (1)
13-13: Transition to RESTClient inClientstruct.The
Clientstruct now embeds*common.RESTClient, indicating a shift towards RESTful communication. Ensure that all methods and functionalities relying on the previous*common.Clientstructure are compatible with the new*common.RESTClient.Run the following script to verify the usage of
Clientstruct methods:Verification successful
Transition to RESTClient in
Clientstruct verified.The transition to embedding
*common.RESTClientin theClientstruct appears to be compatible with existing method calls. Methods likeDoFile,DoStream, andDoURLare usingRESTClientmethods internally, indicating that the change has been properly integrated. No further issues were found in the method usage.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all method calls on `Client` struct instances. # Test: Search for method calls on `Client` instances. Expect: Compatibility with `RESTClient`. rg --type go -A 5 $'Client'Length of output: 148039
pkg/client/manage/v1/types.go (1)
14-14: Verify compatibility withcommon.RESTClient.The
Clientstruct now embeds a pointer tocommon.RESTClient. Ensure thatRESTClientprovides all the necessary methods and properties previously available incommon.Client.Run the following script to verify the methods and properties of
common.RESTClient:pkg/api/listen/v1/websocket/constants.go (2)
17-18: Improved error message clarity.The error message for
ErrUserCallbackNotDefinednow clearly indicates that the callback may be undefined or invalid.
20-21: New error constant for user channel issues.The addition of
ErrUserChanNotDefinedimproves error handling by specifically addressing user channel issues.pkg/api/listen/v1/websocket/interfaces/constants.go (2)
8-9: Enhanced type safety withTypeResponse.The introduction of
TypeResponseimproves type safety and clarity for message type constants.
12-22: Consistent use ofTypeResponsefor message types.The use of
TypeResponsefor all message type constants ensures consistency and enhances code readability.pkg/api/manage/v1/manage.go (1)
31-32: Verify theRESTClientinitialization logic.The
RESTClientis now directly wrapping theclientparameter. Ensure this change aligns with the intended design and does not introduce any unintended side effects.Run the following script to verify the usage and interactions of
RESTClientin the codebase:Verification successful
RESTClient Initialization Logic Verified
The initialization of
RESTClientby directly wrapping theclientparameter is consistent with the intended design and does not introduce any unintended side effects. The usage across the codebase aligns with this pattern.
pkg/api/manage/v1/manage.go: Direct initialization withclient.- Consistent usage in files like
pkg/client/speak/v1/rest/client.go,pkg/client/manage/v1/client.go, etc.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage and interactions of `RESTClient` in the codebase. # Test: Search for the usage of `RESTClient`. Expect: Consistent usage with the new initialization logic. rg --type go -A 5 $'RESTClient'Length of output: 7683
pkg/client/common/v1/interfaces/interfaces.go (1)
8-26: Verify the implementation ofWebSocketHandlerinterface.Ensure that the
WebSocketHandlerinterface is correctly implemented in the relevant parts of the codebase.Run the following script to verify the implementation of the
WebSocketHandlerinterface:Verification successful
WebSocketHandler Interface Implementation Verified
The
WebSocketHandlerinterface is correctly implemented by theWSChannelandWSCallbackstructs in the codebase. All required methods are present and properly defined.
WSChannelandWSCallbackimplement all methods of theWebSocketHandlerinterface:
ProcessMessageProcessErrorStartFinishGetCloseMsgScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `WebSocketHandler` interface. # Test: Search for the implementation of `WebSocketHandler`. Expect: Correct implementation in relevant parts of the codebase. ast-grep --lang go --pattern $'type $_ struct { $$$ }\n\nfunc ($_ *$_) GetURL($_, $_) ($_ , $_) {\n $$$\n}\n\nfunc ($_ *$_) ProcessMessage($_, $_) $_ {\n $$$\n}\n\nfunc ($_ *$_) ProcessError($_) $_ {\n $$$\n}\n\nfunc ($_ *$_) Start() {\n $$$\n}\n\nfunc ($_ *$_) Finish() {\n $$$\n}\n\nfunc ($_ *$_) GetCloseMsg() $_ {\n $$$\n}'Length of output: 1010
Script:
#!/bin/bash # Description: Verify the implementation of `WebSocketHandler` interface by searching for each method separately. # Search for structs implementing the GetURL method ast-grep --lang go --pattern $'func ($_ *$_) GetURL($_, $_) ($_ , $_) { $$$ }' # Search for structs implementing the ProcessMessage method ast-grep --lang go --pattern $'func ($_ *$_) ProcessMessage($_, $_) $_ { $$$ }' # Search for structs implementing the ProcessError method ast-grep --lang go --pattern $'func ($_ *$_) ProcessError($_) $_ { $$$ }' # Search for structs implementing the Start method ast-grep --lang go --pattern $'func ($_ *$_) Start() { $$$ }' # Search for structs implementing the Finish method ast-grep --lang go --pattern $'func ($_ *$_) Finish() { $$$ }' # Search for structs implementing the GetCloseMsg method ast-grep --lang go --pattern $'func ($_ *$_) GetCloseMsg() $_ { $$$ }'Length of output: 8626
pkg/client/common/v1/types.go (2)
44-46: Verify the utilization ofRESTClientstructure.Ensure that the
RESTClientstructure is correctly utilized in the codebase, particularly in handling REST functionalities.Run the following script to verify the utilization of the
RESTClientstructure:Verification successful
RESTClient structure is correctly utilized for REST functionalities.
The
RESTClientstructure is used across various parts of the codebase, includingspeak,manage,analyze, andlistenclients. It provides methods likeSetupRequestandHandleResponse, which are utilized to manage REST operations effectively. The usage patterns confirm its role in handling REST functionalities.
pkg/client/common/v1/rest.go: Defines methods likeSetupRequestandHandleResponse.pkg/client/manage/v1/client.go,pkg/client/analyze/v1/client.go,pkg/client/listen/v1/rest/client.go: UtilizeRESTClientmethods for REST operations.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the utilization of `RESTClient` structure. # Test: Search for the usage of `RESTClient`. Expect: Correct utilization in handling REST functionalities. rg --type go -A 5 $'RESTClient'Length of output: 7683
25-39: Verify the utilization ofWSClientstructure.Ensure that the
WSClientstructure is correctly utilized in the codebase, particularly in handling WebSocket connections.Run the following script to verify the utilization of the
WSClientstructure:Verification successful
WSClient Structure Utilization Verified
The
WSClientstructure is correctly utilized across the codebase for handling WebSocket connections. It is instantiated and its methods are invoked in various files, ensuring comprehensive management of WebSocket operations such as connection, reconnection, and data transmission.
pkg/client/listen/v1/websocket/types.gopkg/client/listen/v1/websocket/new_using_chan.gopkg/client/listen/v1/websocket/client_channel.gopkg/client/listen/v1/websocket/new_using_callbacks.gopkg/client/listen/v1/websocket/client_callback.gopkg/client/common/v1/websocket.goScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the utilization of `WSClient` structure. # Test: Search for the usage of `WSClient`. Expect: Correct utilization in handling WebSocket connections. rg --type go -A 5 $'WSClient'Length of output: 10997
pkg/client/common/v1/constants.go (1)
1-44: Well-structured constants and error definitions.The file provides a centralized location for managing constants and error messages, which enhances maintainability and readability. The definitions are clear and follow best practices.
pkg/api/listen/v1/websocket/interfaces/interfaces.go (1)
8-31: Well-defined interfaces for WebSocket interactions.The new interfaces provide a structured way to handle WebSocket events and message processing, enhancing modularity and flexibility. The definitions are clear and follow best practices.
pkg/client/listen/v1/websocket/types.go (3)
22-24: Deprecation notice is clear and aliasing is correctly implemented.The
Clienttype is correctly aliased toWSCallbackwith a clear deprecation notice.
Line range hint
43-57: Struct modifications forWSChannelalign with channel-based design.The struct modifications are consistent with the channel-oriented approach for handling messages.
Ensure that the
chansfield is properly initialized and used in the implementation.Run the following script to verify the usage of
chansfield:Verification successful
Initialization and Usage of
chansField inWSChannelis Properly HandledThe
chansfield in theWSChannelstruct is correctly initialized and used across various functions for creating instances ofWSChannel. It is initialized as an empty slice, ensuring that it is ready for further operations. No issues were found regarding its usage.
- The
chansfield is initialized in theNewUsingChanWithCancelfunction.- It is consistently passed as an argument in several constructor functions.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the initialization and usage of `chans` field in `WSChannel`. # Test: Search for the usage of `chans` field. Expect: Proper initialization and usage. rg --type go -A 5 'WSChannel' | rg 'chans'Length of output: 3264
26-41: Struct definition forWSCallbackis well-defined.The struct is well-structured with fields for context management and callbacks.
Ensure that the context and callback fields are properly initialized and used in the implementation.
Run the following script to verify the usage of
ctxandcallbackfields:Verification successful
Initialization and Usage of
ctxandcallbackFields inWSCallbackare Properly ManagedThe
ctxandcallbackfields in theWSCallbackstruct are appropriately initialized and used across various functions, ensuring correct context management and callback handling.
- The
ctxfield is initialized and used in functions such asNewUsingCallbackWithCancel,Connect,ConnectWithCancel, andAttemptReconnectWithCancel.- The
callbackfield is initialized inNewUsingCallbackWithCancel.These usages confirm that the fields are managed as intended.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the initialization and usage of `ctx` and `callback` fields in `WSCallback`. # Test: Search for the usage of `ctx` and `callback` fields. Expect: Proper initialization and usage. rg --type go -A 5 'WSCallback' | rg 'ctx|callback'Length of output: 14692
examples/speech-to-text/websocket/http_callback/main.go (1)
40-40: Usage ofNewWSUsingCallbackForDemois correctly integrated.The new method is correctly used to create a Deepgram client.
Ensure that the
NewWSUsingCallbackForDemomethod is properly implemented and tested.Run the following script to verify the implementation of
NewWSUsingCallbackForDemo:Verification successful
The implementation of
NewWSUsingCallbackForDemois verified and correct.The function
NewWSUsingCallbackForDemois properly implemented and callslistenv1ws.NewUsingCallbackForDemo, which sets up the websocket connection using default options. This aligns with its intended use for demonstration purposes. No further issues are found.
- Implementation is located in
pkg/client/listen/v1/websocket/new_using_callbacks.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `NewWSUsingCallbackForDemo`. # Test: Search for the implementation of `NewWSUsingCallbackForDemo`. Expect: Proper implementation. rg --type go -A 5 'NewWSUsingCallbackForDemo'Length of output: 2219
Script:
#!/bin/bash # Description: Verify the implementation of `listenv1ws.NewUsingCallbackForDemo`. # Test: Search for the implementation of `NewUsingCallbackForDemo`. Expect: Proper implementation. rg --type go -A 10 'NewUsingCallbackForDemo'Length of output: 2898
examples/speech-to-text/websocket/http_channel/main.go (1)
24-83: Example code effectively demonstrates channel-based websocket interactions.The example code is clear and functional, showcasing the use of
NewWSUsingChanForDemo.Ensure that the
NewWSUsingChanForDemomethod is properly implemented and tested.Run the following script to verify the implementation of
NewWSUsingChanForDemo:Verification successful
Implementation of
NewWSUsingChanForDemois verified and correct.The function
NewWSUsingChanForDemois properly implemented inpkg/client/listen/client.go, and it effectively creates a websocket connection for demo purposes. No issues were found with its implementation.
pkg/client/listen/client.go: Implementation ofNewWSUsingChanForDemo.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `NewWSUsingChanForDemo`. # Test: Search for the implementation of `NewWSUsingChanForDemo`. Expect: Proper implementation. rg --type go -A 5 'NewWSUsingChanForDemo'Length of output: 1873
pkg/api/listen/v1/websocket/types.go (4)
16-28: LGTM! Struct definition is clear and appropriate.The
DefaultChanHandlerstruct is well-defined for handling different WebSocket events using channels.
31-43: LGTM! Struct definition is clear and appropriate.The
ChanRouterstruct is well-defined for routing events to multiple channel subscribers.
51-54: LGTM! Struct definition is clear and appropriate.The
DefaultCallbackHandlerstruct is straightforward and serves its purpose for handling callbacks.
57-60: LGTM! Struct definition is clear and appropriate.The
CallbackRouterstruct is well-defined for routing events using callbacks.pkg/client/manage/v1/client.go (1)
38-39: LGTM! Change to usecommon.NewRESTis appropriate.The modification to use
common.NewRESTfor client initialization aligns with the intended RESTful interactions..golangci.yaml (1)
109-126: LGTM! Linter path updates are appropriate.The changes to linter paths and configurations enhance linting coverage for websocket-related files.
pkg/client/speak/v1/rest/client.go (1)
54-57: Verify the implementation ofcommon.NewREST.The
Newfunction now usescommon.NewRESTfor client instantiation. Ensure that this change aligns with the intended REST-specific functionality.Run the following script to verify the implementation of
common.NewREST:Verification successful
Verified: Implementation of
common.NewRESTis correct.The
NewRESTfunction properly initializes aRESTClient, handling API key assignment and option parsing with error logging. This aligns with the intended REST-specific functionality. No issues found.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `common.NewREST`. # Test: Search for the function implementation. Expect: Correct implementation of REST client creation. ast-grep --lang go --pattern $'func NewREST($_, $_) *RESTClient { $$$ }'Length of output: 886
pkg/client/live/legacy.go (2)
91-93: Verify the implementation oflistenv1ws.NewUsingCallbackWithCancel.The
NewWithCancelfunction now useslistenv1ws.NewUsingCallbackWithCancel. Ensure that this change aligns with the intended callback management functionality.
72-74: Verify the implementation oflistenv1ws.NewUsingCallbackWithCancel.The
Newfunction now useslistenv1ws.NewUsingCallbackWithCancel. Ensure that this change aligns with the intended callback management functionality.Run the following script to verify the implementation of
listenv1ws.NewUsingCallbackWithCancel:Verification successful
Verified: Implementation of
listenv1ws.NewUsingCallbackWithCancel.The function
NewUsingCallbackWithCancelcorrectly implements context and callback management, aligning with the intended functionality in theNewfunction.
- Located in
pkg/client/listen/v1/websocket/new_using_callbacks.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of `listenv1ws.NewUsingCallbackWithCancel`. # Test: Search for the function implementation. Expect: Correct implementation of callback management. ast-grep --lang go --pattern $'func NewUsingCallbackWithCancel($_, $_, $_, $_, $_, $_) (*Client, error) { $$$ }'Length of output: 113
Script:
#!/bin/bash # Search for any occurrences of `NewUsingCallbackWithCancel` in the codebase to verify its existence or find similar functions. rg 'NewUsingCallbackWithCancel'Length of output: 996
Script:
#!/bin/bash # Extract the implementation details of `NewUsingCallbackWithCancel` from its definition file. ast-grep --lang go --pattern $'func NewUsingCallbackWithCancel($_, $_, $_, $_, $_, $_) (*WSCallback, error) { $$$ }'Length of output: 3911
pkg/client/common/v1/rest.go (3)
Line range hint
39-59: LGTM!The
SetupRequestmethod is now associated withRESTClient, enhancing clarity regarding its purpose.
Line range hint
66-100: LGTM!The
HandleResponsemethod is now associated withRESTClient, enhancing clarity regarding its purpose.
Line range hint
21-34: Verify the implementation ofrestv1.New.The
NewRESTfunction usesrestv1.Newfor client instantiation. Ensure that this change aligns with the intended REST-specific functionality.Run the following script to verify the implementation of
restv1.New:pkg/client/listen/v1/websocket/new_using_chan.go (4)
25-27: LGTM!The function
NewUsingChanForDemocorrectly delegates toNewUsingChanwith default parameters.
36-38: LGTM!The function
NewUsingChanWithDefaultscorrectly delegates toNewUsingChanwith default parameters and a channel handler.
50-53: LGTM!The function
NewUsingChancorrectly initializes a context with cancellation and delegates toNewUsingChanWithCancel.
66-111: LGTM!The function
NewUsingChanWithCancelis well-implemented with appropriate error handling and default channel handler setup.examples/speech-to-text/websocket/microphone_callback/main.go (2)
153-153: LGTM!The Deepgram client is correctly instantiated using
NewWSUsingCallbackwith the appropriate parameters.
Line range hint
1-152: Well-structured example!The example effectively demonstrates the usage of the new WebSocket client with a custom callback and microphone input.
Also applies to: 154-223
pkg/api/listen/v1/websocket/callback_router.go (3)
18-42: LGTM!The creation functions for
CallbackRouterare correctly implemented with clear deprecation notices.
Line range hint
48-195: LGTM!The methods of
CallbackRouterare well-implemented with clear routing logic for various message types.
Line range hint
146-192: LGTM!The
MessageandUnhandledMessagemethods are robust and handle message routing and logging effectively.pkg/api/listen/v1/websocket/callback_default.go (9)
20-34: Efficient use of environment variables for debugging.The introduction of
debugWebsocketanddebugWebsocketVerbosefields to handle debug logging is a good improvement. It reduces redundancy and centralizes the logic for checking debug settings.
Line range hint
38-60: Refactored debug logic inOpenmethod.The refactoring of the
Openmethod to usedebugWebsocketfor logging is efficient and improves readability.
Line range hint
64-98: Refactored debug logic inMessagemethod.The
Messagemethod now usesdebugWebsocketfor logging, which is consistent with the refactoring pattern.
Line range hint
100-125: Refactored debug logic inMetadatamethod.The
Metadatamethod now usesdebugWebsocketfor logging, maintaining consistency across methods.
Line range hint
127-146: Refactored debug logic inSpeechStartedmethod.The
SpeechStartedmethod uses bothdebugWebsocketanddebugWebsocketVerbosefor logging, which is a good use of the new fields.
161-163: Verbose logging inUtteranceEndmethod.The use of
debugWebsocketVerbosefor additional logging in theUtteranceEndmethod is consistent with the intended functionality.
Line range hint
170-193: Refactored debug logic inClosemethod.The
Closemethod now usesdebugWebsocketfor logging, which aligns with the refactoring strategy.
Line range hint
195-222: Refactored debug logic inErrormethod.The
Errormethod usesdebugWebsocketfor logging, which is consistent with other methods.
Line range hint
224-238: Refactored debug logic inUnhandledEventmethod.The
UnhandledEventmethod now usesdebugWebsocketfor logging, maintaining consistency.pkg/client/listen/v1/websocket/new_using_callbacks.go (7)
19-29: Deprecation notice forNewForDemo.The function
NewForDemois deprecated in favor ofNewUsingCallbackForDemo. Ensure that documentation and usage examples reflect this change.
31-39: Implementation ofNewUsingCallbackForDemo.The function
NewUsingCallbackForDemoprovides a streamlined way to create websocket connections with default options, which is useful for demonstrations.
41-53: Deprecation notice forNewWithDefaults.The function
NewWithDefaultsis deprecated in favor ofNewUsingCallbackWithDefaults. Ensure that documentation and usage examples reflect this change.
55-63: Implementation ofNewUsingCallbackWithDefaults.The function
NewUsingCallbackWithDefaultsoffers a clear way to create websocket connections with default options and a specified callback.
65-79: Deprecation notice forNew.The function
Newis deprecated in favor ofNewUsingCallback. Ensure that documentation and usage examples reflect this change.
81-94: Implementation ofNewUsingCallback.The function
NewUsingCallbackeffectively sets up websocket connections with specified options and a callback, utilizing context for cancellation.
96-149: Comprehensive setup inNewUsingCallbackWithCancel.The function
NewUsingCallbackWithCancelprovides a thorough setup for websocket connections, including context management and error handling.pkg/client/listen/v1/rest/client.go (4)
60-62: Transition tocommon.NewREST.The use of
common.NewRESTin theNewfunction indicates a shift to a REST-specific client, which may enhance API interactions. Ensure that this change is reflected in any related documentation or usage examples.
Line range hint
64-102: Robust error handling inDoFile.The
DoFilefunction includes comprehensive error handling for file operations, which is crucial for reliability.
Line range hint
104-152: Efficient stream handling inDoStream.The
DoStreamfunction efficiently sets up and executes streaming requests, with detailed logging for troubleshooting.
Line range hint
154-203: URL validation inDoURL.The
DoURLfunction includes robust URL validation and error handling, ensuring reliable operation.pkg/client/analyze/v1/client.go (1)
62-62: LGTM! The shift tocommon.NewRESTis appropriate.The change aligns the client initialization with REST-specific functionality, which is consistent with the file's purpose.
examples/speech-to-text/websocket/microphone_channel/main.go (4)
24-33: LGTM! The channel-based struct is well-organized.The
MyHandlerstruct effectively uses channels to handle asynchronous WebSocket events.
35-52: LGTM! The handler initialization and goroutine setup are appropriate.The
NewMyHandlerfunction correctly sets up theMyHandlerstruct and starts it in a goroutine for concurrent processing.
96-201: LGTM! TheRunfunction is well-structured for concurrent event handling.The use of goroutines and a wait group ensures efficient processing of asynchronous events.
203-308: LGTM! Themainfunction demonstrates a clear setup and teardown process.The function effectively initializes the microphone, sets up the Deepgram client, and handles errors and resource cleanup.
pkg/api/listen/v1/websocket/chan_default.go (3)
20-43: LGTM! The channel-based struct is well-organized.The
DefaultChanHandlerstruct effectively uses channels to handle asynchronous WebSocket events.
21-53: LGTM! The handler initialization and goroutine setup are appropriate.The
NewDefaultChanHandlerfunction correctly sets up theDefaultChanHandlerstruct and starts it in a goroutine for concurrent processing.
98-329: LGTM! TheRunfunction is well-structured for concurrent event handling.The use of goroutines and a wait group ensures efficient processing of asynchronous events.
pkg/api/listen/v1/websocket/chan_router.go (14)
40-73: Verify the usage ofDEEPGRAM_DEBUG.Ensure that the
DEEPGRAM_DEBUGenvironment variable is consistently used across the codebase for debugging purposes.
75-97: LGTM!The
Openfunction is implemented correctly with appropriate error handling.
99-121: LGTM!The
Closefunction is implemented correctly with appropriate error handling.
123-145: LGTM!The
Errorfunction is implemented correctly with appropriate error handling.
147-162: LGTM!The
processGenericfunction is implemented correctly with appropriate logging and error handling.
164-179: LGTM!The
processMessagefunction is implemented correctly with appropriate error handling.
181-196: LGTM!The
processMetadatafunction is implemented correctly with appropriate error handling.
198-213: LGTM!The
processSpeechStartedResponsefunction is implemented correctly with appropriate error handling.
215-230: LGTM!The
processUtteranceEndResponsefunction is implemented correctly with appropriate error handling.
232-247: LGTM!The
processErrorResponsefunction is implemented correctly with appropriate error handling.
249-287: LGTM!The
Messagefunction is implemented correctly with appropriate logging and error handling.
289-301: LGTM!The
UnhandledMessagefunction is implemented correctly with appropriate logging and error handling.
303-313: LGTM!The
printDebugMessagesfunction is implemented correctly with appropriate error handling for JSON formatting.
18-38: Verify the usage ofDEEPGRAM_DEBUG.Ensure that the
DEEPGRAM_DEBUGenvironment variable is consistently used across the codebase for debugging purposes.Run the following script to verify the usage of
DEEPGRAM_DEBUG:Verification successful
Consistent usage of
DEEPGRAM_DEBUGconfirmed.The
DEEPGRAM_DEBUGenvironment variable is consistently used across the codebase for debugging purposes, particularly within thewebsocketpackage. This aligns with standard practices for handling debug configurations.
- Files using
DEEPGRAM_DEBUG:
pkg/api/listen/v1/websocket/callback_router.gopkg/api/listen/v1/websocket/chan_router.gopkg/api/listen/v1/websocket/callback_default.gopkg/api/listen/v1/websocket/chan_default.goScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistent usage of DEEPGRAM_DEBUG environment variable. # Test: Search for occurrences of DEEPGRAM_DEBUG. Expect: Consistent usage across the codebase. rg --type go -A 2 $'DEEPGRAM_DEBUG'Length of output: 2503
pkg/client/listen/v1/websocket/client_callback.go (17)
25-29: LGTM!The
Connectfunction is implemented correctly with appropriate context management.
31-37: LGTM!The
ConnectWithCancelfunction is implemented correctly with appropriate context management.
39-43: LGTM!The
AttemptReconnectfunction is implemented correctly with appropriate context management.
45-50: LGTM!The
AttemptReconnectWithCancelfunction is implemented correctly with appropriate context management.
52-61: LGTM!The
GetURLfunction is implemented correctly with appropriate error handling and logging.
63-71: LGTM!The
Startfunction is implemented correctly with appropriate checks for configuration options.
73-103: LGTM!The
ProcessMessagefunction is implemented correctly with appropriate error handling and logging.
105-155: LGTM!The
Streamfunction is implemented correctly with appropriate error handling and logging.
157-175: LGTM!The
Writefunction is implemented correctly with appropriate error handling and logging.
177-195: LGTM!The
KeepAlivefunction is implemented correctly with appropriate error handling and logging.
197-215: LGTM!The
Finalizefunction is implemented correctly with appropriate error handling and logging.
217-220: LGTM!The
GetCloseMsgfunction is implemented correctly.
222-225: LGTM!The
Finishfunction is implemented correctly as a placeholder.
227-236: LGTM!The
ProcessErrorfunction is implemented correctly with appropriate error handling and logging.
238-279: LGTM!The
pingfunction is implemented correctly with appropriate error handling and logging.
281-344: LGTM!The
flushfunction is implemented correctly with appropriate error handling and logging.
346-372: LGTM!The
errorToResponsefunction is implemented correctly with appropriate error handling and formatting.pkg/client/listen/v1/websocket/client_channel.go (17)
25-29: LGTM!The
Connectfunction is implemented correctly with appropriate context management.
31-37: LGTM!The
ConnectWithCancelfunction is implemented correctly with appropriate context management.
39-43: LGTM!The
AttemptReconnectfunction is implemented correctly with appropriate context management.
45-50: LGTM!The
AttemptReconnectWithCancelfunction is implemented correctly with appropriate context management.
52-61: LGTM!The
GetURLfunction is implemented correctly with appropriate error handling and logging.
63-71: LGTM!The
Startfunction is implemented correctly with appropriate checks for configuration options.
73-103: LGTM!The
ProcessMessagefunction is implemented correctly with appropriate error handling and logging.
105-155: LGTM!The
Streamfunction is implemented correctly with appropriate error handling and logging.
157-175: LGTM!The
Writefunction is implemented correctly with appropriate error handling and logging.
177-195: LGTM!The
KeepAlivefunction is implemented correctly with appropriate error handling and logging.
197-215: LGTM!The
Finalizefunction is implemented correctly with appropriate error handling and logging.
217-220: LGTM!The
GetCloseMsgfunction is implemented correctly.
222-225: LGTM!The
Finishfunction is implemented correctly as a placeholder.
227-236: LGTM!The
ProcessErrorfunction is implemented correctly with appropriate error handling and logging.
238-279: LGTM!The
pingfunction is implemented correctly with appropriate error handling and logging.
281-344: LGTM!The
flushfunction is implemented correctly with appropriate error handling and logging.
346-372: LGTM!The
errorToResponsefunction is implemented correctly with appropriate error handling and formatting.pkg/client/common/v1/websocket.go (4)
80-210: Review the use ofInsecureSkipVerify.The
InsecureSkipVerifyoption intls.Configis set totrue, which can expose the connection to man-in-the-middle attacks. Ensure this is intentional and document the security implications.
347-379: LGTM!The
WriteBinaryfunction is well-implemented and handles locking and error logging appropriately.
381-423: LGTM!The
WriteJSONfunction is well-implemented and handles JSON marshaling, locking, and error logging appropriately.
505-513: LGTM!The
Stopfunction is well-implemented and handles stopping the WebSocket connection gracefully.pkg/client/listen/client.go (20)
73-74: LGTM!The
NewWSUsingCallbackForDemofunction is well-implemented and correctly delegates to the underlying implementation.
77-81: LGTM!The
NewWebSocketUsingCallbackForDemofunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
95-96: LGTM!The
NewWSUsingCallbackWithDefaultsfunction is well-implemented and correctly delegates to the underlying implementation.
99-103: LGTM!The
NewWebSocketUsingCallbackWithDefaultsfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
119-121: LGTM!The
NewWSUsingCallbackfunction is well-implemented and correctly delegates to the underlying implementation.
124-128: LGTM!The
NewWebSocketUsingCallbackfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
145-147: LGTM!The
NewWSUsingCallbackWithCancelfunction is well-implemented and correctly delegates to the underlying implementation.
149-153: LGTM!The
NewWebSocketUsingCallbackWithCancelfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
168-170: LGTM!The
NewWSUsingChanForDemofunction is well-implemented and correctly delegates to the underlying implementation.
172-176: LGTM!The
NewWebSocketUsingChanForDemofunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
189-191: LGTM!The
NewWSUsingChanWithDefaultsfunction is well-implemented and correctly delegates to the underlying implementation.
193-197: LGTM!The
NewWebSocketUsingChanWithDefaultsfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
209-211: LGTM!The
NewWSUsingChanfunction is well-implemented and correctly delegates to the underlying implementation.
214-218: LGTM!The
NewWebSocketUsingChanfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
231-233: LGTM!The
NewWSUsingChanWithCancelfunction is well-implemented and correctly delegates to the underlying implementation.
235-239: LGTM!The
NewWebSocketUsingChanWithCancelfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
252-254: LGTM!The
NewWebSocketForDemofunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
263-265: LGTM!The
NewWebSocketWithDefaultsfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
274-276: LGTM!The
NewWebSocketfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
285-287: LGTM!The
NewWebSocketWithCancelfunction is correctly implemented as an alias. Note the TODO comment for future deprecation.
davidvonthenen
changed the title
Proposed changes
Addresses: #215
This implements a mechanism for using Go channels to get callbacks to events. This has been requested numerous times (example). This was deferred work since the project began, but there have been enough requests to make this a reality. This feature is required for upcoming STS work, so we need to get it in early to shake out any bugs.
Advantages of using the channel method:
This preserves the existing callback using the functions method.
This implements two examples:
examples/speech-to-text/http_channelexamples/speech-to-text/microphone_channelTypes of changes
What types of changes does your code introduce to the community Go SDK?
Put an
xin the boxes that applyChecklist
Put an
xin 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
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
Documentation