feat: adds ttl_seconds support #557
Conversation
WalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Client
participant AuthRESTClient
User->>Client: call grant_token(ttl_seconds)
Client->>AuthRESTClient: grant_token(ttl_seconds)
alt ttl_seconds is valid or None
AuthRESTClient->>AuthRESTClient: validate ttl_seconds
AuthRESTClient->>AuthRESTClient: build request body (with or without ttl_seconds)
AuthRESTClient->>AuthRESTClient: send POST /token request
AuthRESTClient-->>Client: return token response
Client-->>User: return token
else ttl_seconds is invalid
AuthRESTClient->>AuthRESTClient: raise ValueError
AuthRESTClient-->>Client: exception
Client-->>User: exception
end
Possibly related PRs
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Pylint (3.3.7)deepgram/clients/auth/v1/async_client.pydeepgram/clients/auth/v1/client.py📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 using PR comments)
Other keywords and placeholders
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: 0
🧹 Nitpick comments (5)
tests/response_data/speak/rest/1fe0ad339338a9d6cffbab2c7ace41ba5387b5fe7906854795702dce91034fd3-f8c3bf62a9aa3e6fc1619c250e48abe7519373d3edf41be62eb5dc45199af2ef-response.json (1)
1-1: Consider normalizing volatile fields in recorded fixtures
request_idanddatechange on every live call, so committing them verbatim makes future snapshot updates noisy. Stripping or stubbing these values (e.g.,"request_id": "<any>", fixed epoch) keeps diffs minimal and avoids unnecessary fixture churn while still testing payload structure.If you agree, I can draft a helper that post-processes TTS fixtures to blank these fields before committing.
tests/response_data/listen/rest/c4e1c0031174878d8f0e3dbd87916ee16d56f1c610ac525af5712ea37226a455-29e7c8100617f70da4ae9da1921cb5071a01219f4780ca70930b0a370ed2163a-response.json (1)
1-1: Strip volatile metadata to keep fixtures stable
request_idandcreatedare inherently dynamic. Keeping them in committed fixtures guarantees noisy diffs on every regeneration and inflates review churn. Consider redacting or normalising these fields (e.g.,"request_id": "<ignored>","created": 0) before committing.- "request_id": "426529dd-f7d5-4295-99ea-6c6baf31721e", - "created": "2025-07-17T15:22:05.147Z", + "request_id": "<ignored>", + "created": 0,Most snapshot/fixture libraries allow post-processing hooks—worth using here.
tests/response_data/listen/rest/a231370d439312b1a404bb6ad8de955e900ec8eae9a906329af8cc672e6ec7ba-29e7c8100617f70da4ae9da1921cb5071a01219f4780ca70930b0a370ed2163a-response.json (1)
1-1: Volatile metadata fields (request_id,created,sha256) make fixtures noisy.These auto-generated values change on every recording, so any small re-capture forces an otherwise meaningless diff and pollutes PR history. Consider:
- Trimming/omitting volatile keys when serialising fixtures;
- Replacing them with deterministic placeholders (e.g.
"REQUEST_ID_PLACEHOLDER"); or- Normalising them inside the test harness (load JSON, overwrite the keys before comparison).
This keeps test data stable and reviews cleaner without losing coverage.
tests/response_data/listen/rest/a231370d439312b1a404bb6ad8de955e900ec8eae9a906329af8cc672e6ec7ba-a17f4880c5b4cf124ac54d06d77c9f0ab7f3fe1052ff1c7b090f7eaf8ede5b76-response.json (1)
1-1: Pretty-print fixture for maintainabilityThe entire JSON blob is stored on a single line. This makes diffs noisy (e.g., this change touches the whole file even though only a couple of fields were updated) and hard to review manually. Storing fixtures in a consistent, multi-line, indented format keeps future diffs minimal and readable.
-{"metadata": {...}} +{ + "metadata": { + ... + }, + "results": { + ... + } +}A one-liner is fine at runtime, but in VCS a formatted version will save time for reviewers.
tests/response_data/listen/rest/c4e1c0031174878d8f0e3dbd87916ee16d56f1c610ac525af5712ea37226a455-a17f4880c5b4cf124ac54d06d77c9f0ab7f3fe1052ff1c7b090f7eaf8ede5b76-response.json (1)
1-1: Volatile metadata & single-line JSON make the fixture noisy and fragileThe only differences from the previous revision are values such as
request_id,created, and some minor floating-point drift. These fields change on every real request, so committing the updated blob provides no coverage benefit and bloats diffs. Unit tests that need the transcript can:
- Strip/ignore known-volatile keys (
request_id,created, maybe confidences beyond a tolerance) instead of snapshotting them.- Store the fixture in a pretty-printed, multi-line format (
json.dumps(obj, indent=2, sort_keys=True)) for readability and to minimise diff noise.Consider regenerating the fixture with stable values or validating only the deterministic parts (transcript text, model id, word count, etc.) to keep future PRs clean.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
tests/response_data/speak/rest/1fe0ad339338a9d6cffbab2c7ace41ba5387b5fe7906854795702dce91034fd3-f8c3bf62a9aa3e6fc1619c250e48abe7519373d3edf41be62eb5dc45199af2ef.wavis excluded by!**/*.wav
📒 Files selected for processing (15)
deepgram/clients/auth/v1/async_client.py(1 hunks)deepgram/clients/auth/v1/client.py(1 hunks)examples/auth/async_token/main.py(1 hunks)examples/auth/bearer_token_demo/main.py(1 hunks)examples/auth/token/main.py(1 hunks)tests/response_data/listen/rest/a231370d439312b1a404bb6ad8de955e900ec8eae9a906329af8cc672e6ec7ba-29e7c8100617f70da4ae9da1921cb5071a01219f4780ca70930b0a370ed2163a-response.json(1 hunks)tests/response_data/listen/rest/a231370d439312b1a404bb6ad8de955e900ec8eae9a906329af8cc672e6ec7ba-a17f4880c5b4cf124ac54d06d77c9f0ab7f3fe1052ff1c7b090f7eaf8ede5b76-response.json(1 hunks)tests/response_data/listen/rest/c4e1c0031174878d8f0e3dbd87916ee16d56f1c610ac525af5712ea37226a455-29e7c8100617f70da4ae9da1921cb5071a01219f4780ca70930b0a370ed2163a-response.json(1 hunks)tests/response_data/listen/rest/c4e1c0031174878d8f0e3dbd87916ee16d56f1c610ac525af5712ea37226a455-a17f4880c5b4cf124ac54d06d77c9f0ab7f3fe1052ff1c7b090f7eaf8ede5b76-response.json(1 hunks)tests/response_data/listen/websocket/ed5bfd217988aa8cad492f63f79dc59f5f02fb9b85befe6f6ce404b8f19aaa0d-42fc5ed98cabc1fa1a2f276301c27c46dd15f6f5187cd93d944cc94fa81c8469-response.json(1 hunks)tests/response_data/listen/websocket/ed5bfd217988aa8cad492f63f79dc59f5f02fb9b85befe6f6ce404b8f19aaa0d-d7334c26cf6468c191e05ff5e8151da9b67985c66ab177e9446fd14bbafd70df-response.json(1 hunks)tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-error.json(1 hunks)tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-response.json(1 hunks)tests/response_data/speak/rest/1fe0ad339338a9d6cffbab2c7ace41ba5387b5fe7906854795702dce91034fd3-f8c3bf62a9aa3e6fc1619c250e48abe7519373d3edf41be62eb5dc45199af2ef-response.json(1 hunks)tests/unit_test/test_unit_grant_token.py(1 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: lukeocodes
PR: deepgram/deepgram-python-sdk#543
File: tests/unit_test/test_unit_authentication.py:67-87
Timestamp: 2025-06-22T17:02:32.416Z
Learning: When both api_key and access_token are explicitly provided via named parameters in the Deepgram Python SDK, access tokens should take precedence according to the documented priority order: explicit access_token parameter (highest), explicit api_key parameter, DEEPGRAM_ACCESS_TOKEN environment variable, and DEEPGRAM_API_KEY environment variable (lowest).
examples/auth/async_token/main.py (6)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-10-09T02:19:48.728Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-06-12T18:02:10.651Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/client.py:81-81
Timestamp: 2024-06-27T00:06:01.811Z
Learning: Imports for SpeakStreamClient and AsyncSpeakStreamClient in `deepgram/client.py` are necessary for export purposes and should not be flagged as unused in reviews.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/client.py:81-81
Timestamp: 2024-10-09T02:19:46.087Z
Learning: Imports for SpeakStreamClient and AsyncSpeakStreamClient in `deepgram/client.py` are necessary for export purposes and should not be flagged as unused in reviews.
Learnt from: lukeocodes
PR: deepgram/deepgram-python-sdk#543
File: tests/unit_test/test_unit_authentication.py:67-87
Timestamp: 2025-06-22T17:02:32.416Z
Learning: When both api_key and access_token are explicitly provided via named parameters in the Deepgram Python SDK, access tokens should take precedence according to the documented priority order: explicit access_token parameter (highest), explicit api_key parameter, DEEPGRAM_ACCESS_TOKEN environment variable, and DEEPGRAM_API_KEY environment variable (lowest).
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#472
File: examples/speech-to-text/websocket/replay/main.py:78-80
Timestamp: 2024-10-18T16:20:17.742Z
Learning: In the `examples` directory of the Deepgram Python SDK, code is intended as illustrative examples and doesn't require production-level error handling.
examples/auth/token/main.py (8)
Learnt from: lukeocodes
PR: deepgram/deepgram-python-sdk#543
File: tests/unit_test/test_unit_authentication.py:67-87
Timestamp: 2025-06-22T17:02:32.416Z
Learning: When both api_key and access_token are explicitly provided via named parameters in the Deepgram Python SDK, access tokens should take precedence according to the documented priority order: explicit access_token parameter (highest), explicit api_key parameter, DEEPGRAM_ACCESS_TOKEN environment variable, and DEEPGRAM_API_KEY environment variable (lowest).
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-10-09T02:19:48.728Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-06-12T18:02:10.651Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#472
File: examples/speech-to-text/websocket/replay/main.py:78-80
Timestamp: 2024-10-18T16:20:17.742Z
Learning: In the `examples` directory of the Deepgram Python SDK, code is intended as illustrative examples and doesn't require production-level error handling.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/speak/__init__.py:16-19
Timestamp: 2024-10-09T02:19:46.087Z
Learning: Unused imports in `deepgram/clients/speak/__init__.py` are retained for backward compatibility and should not be flagged for removal in reviews.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/speak/__init__.py:16-19
Timestamp: 2024-07-01T19:12:57.715Z
Learning: Unused imports in `deepgram/clients/speak/__init__.py` are retained for backward compatibility and should not be flagged for removal in reviews.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/listen/v1/__init__.py:36-43
Timestamp: 2024-10-09T02:19:46.086Z
Learning: Unused imports in `deepgram/clients/listen/v1/__init__.py` are retained to maintain backward compatibility and should not be flagged for removal in reviews.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/listen/v1/__init__.py:36-43
Timestamp: 2024-07-01T19:17:04.194Z
Learning: Unused imports in `deepgram/clients/listen/v1/__init__.py` are retained to maintain backward compatibility and should not be flagged for removal in reviews.
tests/response_data/speak/rest/1fe0ad339338a9d6cffbab2c7ace41ba5387b5fe7906854795702dce91034fd3-f8c3bf62a9aa3e6fc1619c250e48abe7519373d3edf41be62eb5dc45199af2ef-response.json (3)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#472
File: examples/text-to-speech/websocket/output_to_wav/main.py:16-17
Timestamp: 2024-10-18T00:30:20.224Z
Learning: In `examples/text-to-speech/websocket/output_to_wav/main.py`, the hardcoded values for `AUDIO_FILE` and `TTS_TEXT` are intentional and should remain as is.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#472
File: examples/text-to-speech/websocket/output_to_wav/main.py:52-56
Timestamp: 2024-10-18T00:30:04.220Z
Learning: In `examples/text-to-speech/websocket/output_to_wav/main.py`, the code is intended as an example demonstrating functionality, and refactoring suggestions may not be necessary.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#472
File: examples/text-to-speech/websocket/output_to_wav/main.py:38-41
Timestamp: 2024-10-18T00:30:01.884Z
Learning: In the `examples/text-to-speech/websocket/output_to_wav/main.py` file, the code is intended as a simple example, and additional error handling for file operations is not required.
deepgram/clients/auth/v1/client.py (1)
Learnt from: lukeocodes
PR: deepgram/deepgram-python-sdk#543
File: tests/unit_test/test_unit_authentication.py:67-87
Timestamp: 2025-06-22T17:02:32.416Z
Learning: When both api_key and access_token are explicitly provided via named parameters in the Deepgram Python SDK, access tokens should take precedence according to the documented priority order: explicit access_token parameter (highest), explicit api_key parameter, DEEPGRAM_ACCESS_TOKEN environment variable, and DEEPGRAM_API_KEY environment variable (lowest).
tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-response.json (2)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/clients/speak/v1/response.py:48-209
Timestamp: 2024-10-09T02:19:48.728Z
Learning: User dvonthenen prefers to defer certain suggestions, specifically regarding error handling and documentation enhancements in new data classes of `deepgram/clients/speak/v1/response.py`, and may revisit them later.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/clients/speak/v1/response.py:48-209
Timestamp: 2024-06-27T00:06:23.128Z
Learning: User dvonthenen prefers to defer certain suggestions, specifically regarding error handling and documentation enhancements in new data classes of `deepgram/clients/speak/v1/response.py`, and may revisit them later.
tests/response_data/listen/websocket/ed5bfd217988aa8cad492f63f79dc59f5f02fb9b85befe6f6ce404b8f19aaa0d-42fc5ed98cabc1fa1a2f276301c27c46dd15f6f5187cd93d944cc94fa81c8469-response.json (2)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/listen/v1/websocket/__init__.py:8-8
Timestamp: 2024-07-01T19:21:39.778Z
Learning: Unused imports in `deepgram/clients/listen/v1/websocket/__init__.py` are retained to maintain backward compatibility and should not be flagged for removal in reviews.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#426
File: deepgram/clients/listen/v1/websocket/__init__.py:8-8
Timestamp: 2024-10-09T02:19:46.086Z
Learning: Unused imports in `deepgram/clients/listen/v1/websocket/__init__.py` are retained to maintain backward compatibility and should not be flagged for removal in reviews.
deepgram/clients/auth/v1/async_client.py (1)
Learnt from: lukeocodes
PR: deepgram/deepgram-python-sdk#543
File: tests/unit_test/test_unit_authentication.py:67-87
Timestamp: 2025-06-22T17:02:32.416Z
Learning: When both api_key and access_token are explicitly provided via named parameters in the Deepgram Python SDK, access tokens should take precedence according to the documented priority order: explicit access_token parameter (highest), explicit api_key parameter, DEEPGRAM_ACCESS_TOKEN environment variable, and DEEPGRAM_API_KEY environment variable (lowest).
tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-error.json (2)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/clients/speak/v1/response.py:48-209
Timestamp: 2024-10-09T02:19:48.728Z
Learning: User dvonthenen prefers to defer certain suggestions, specifically regarding error handling and documentation enhancements in new data classes of `deepgram/clients/speak/v1/response.py`, and may revisit them later.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#424
File: deepgram/clients/speak/v1/response.py:48-209
Timestamp: 2024-06-27T00:06:23.128Z
Learning: User dvonthenen prefers to defer certain suggestions, specifically regarding error handling and documentation enhancements in new data classes of `deepgram/clients/speak/v1/response.py`, and may revisit them later.
tests/unit_test/test_unit_grant_token.py (2)
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-10-09T02:19:48.728Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
Learnt from: dvonthenen
PR: deepgram/deepgram-python-sdk#417
File: deepgram/clients/live/v1/client.py:14-14
Timestamp: 2024-06-12T18:02:10.651Z
Learning: Ignore suggestions to change import paths to local versions in test cases and examples as per user preference to use the actual `deepgram-sdk` package for testing.
🧬 Code Graph Analysis (4)
examples/auth/token/main.py (2)
deepgram/client.py (2)
auth(538-542)v(628-697)deepgram/clients/auth/v1/client.py (1)
grant_token(31-78)
deepgram/clients/auth/v1/client.py (1)
deepgram/clients/auth/v1/async_client.py (1)
grant_token(31-78)
deepgram/clients/auth/v1/async_client.py (1)
deepgram/clients/auth/v1/client.py (1)
grant_token(31-78)
tests/unit_test/test_unit_grant_token.py (3)
deepgram/client.py (3)
DeepgramClient(408-699)auth(538-542)asyncauth(545-549)deepgram/clients/auth/v1/async_client.py (1)
grant_token(31-78)deepgram/clients/auth/v1/client.py (1)
grant_token(31-78)
🔇 Additional comments (20)
tests/response_data/listen/rest/a231370d439312b1a404bb6ad8de955e900ec8eae9a906329af8cc672e6ec7ba-a17f4880c5b4cf124ac54d06d77c9f0ab7f3fe1052ff1c7b090f7eaf8ede5b76-response.json (1)
1-1: Confirm necessity of metadata churnOnly
request_idandcreatedvalues appear to have changed. If these fields are not functionally relevant for the assertions in your tests, consider stripping or stubbing them out so the file doesn’t need to change on every regeneration, which reduces commit noise and risk of merge conflicts.tests/response_data/listen/websocket/ed5bfd217988aa8cad492f63f79dc59f5f02fb9b85befe6f6ce404b8f19aaa0d-d7334c26cf6468c191e05ff5e8151da9b67985c66ab177e9446fd14bbafd70df-response.json (1)
1-1: LGTM: Routine test data maintenanceThis is a standard metadata update refreshing the
request_idfield in the websocket response test data, which is common maintenance for test fixtures.tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-response.json (1)
1-1: LGTM: Test data enhancementThis update includes both metadata refresh (request_id, timestamp) and content improvements to the summary text. The enhanced content and increased token count (112→146) reflect legitimate improvements to the test data.
tests/response_data/listen/websocket/ed5bfd217988aa8cad492f63f79dc59f5f02fb9b85befe6f6ce404b8f19aaa0d-42fc5ed98cabc1fa1a2f276301c27c46dd15f6f5187cd93d944cc94fa81c8469-response.json (1)
1-1: LGTM: Test data content updateThis update replaces the transcript content and associated timing/confidence data with new audio segment results. The JSON structure remains consistent and the change appears to be legitimate test data maintenance.
examples/auth/bearer_token_demo/main.py (1)
33-35: LGTM: Excellent demonstration of TTL functionalityThe example properly demonstrates the new
ttl_secondsparameter with a reasonable value (600 seconds) and clear documentation through comments and print statements.examples/auth/async_token/main.py (1)
26-44: LGTM: Comprehensive TTL demonstrationThis example excellently demonstrates the new TTL functionality with multiple test cases covering default behavior, custom values, and boundary conditions. The async/await usage is correct and the descriptive output helps users understand the feature.
examples/auth/token/main.py (1)
25-43: Excellent comprehensive demonstration of the TTL feature!The example effectively showcases all key aspects of the new
ttl_secondsparameter:
- Default behavior without specifying TTL
- Custom TTL values (300 seconds)
- Boundary testing with minimum (1 second) and maximum (3600 seconds) values
- Clear output messages for each test case
This provides developers with a complete understanding of how to use the TTL feature.
tests/response_data/read/rest/3917a1c81c08e360c0d4bba0ff9ebd645e610e4149483e5f2888a2c5df388b37-23e873efdfd4d680286fda14ff8f10864218311e79efc92ecc82bce3e574c366-error.json (1)
1-1: Test fixture content improvements look good.The updates to the response data improve terminology ("voice-premises" correction) and add relevant product mentions. The JSON structure is valid and the content enhancements appear appropriate for test fixtures.
deepgram/clients/auth/v1/async_client.py (4)
31-31: Method signature updated correctly for TTL support.The addition of the optional
ttl_secondsparameter with proper type annotation is well-implemented.
33-44: Excellent docstring documentation.The docstring clearly explains:
- Parameter purpose and constraints (1-3600 seconds)
- Default behavior (30 seconds)
- Exception types and conditions
48-51: Robust input validation implementation.The validation correctly:
- Checks for integer type while excluding booleans (important since
boolis a subclass ofintin Python)- Validates the range constraints (1-3600 seconds)
- Raises appropriate
ValueErrorwith clear message
56-71: Proper conditional request body construction.The implementation correctly:
- Constructs request body only when
ttl_secondsis provided- Uses appropriate request paths (with/without JSON body)
- Maintains proper authorization headers in both cases
This ensures backward compatibility while adding the new functionality.
deepgram/clients/auth/v1/client.py (4)
31-31: Method signature correctly updated for TTL support.The addition of the optional
ttl_secondsparameter maintains backward compatibility while adding the new functionality.
33-44: Comprehensive docstring documentation.The docstring mirrors the async version and provides clear information about parameter constraints, default behavior, and exception handling.
48-51: Consistent input validation with async implementation.The validation logic is identical to the async version, ensuring consistent behavior across both client types. The boolean exclusion is particularly important for preventing
True/Falsevalues from being treated as1/0.
56-71: Proper request handling with conditional body construction.The implementation correctly handles both scenarios:
- Sends JSON body when
ttl_secondsis provided- Sends request without body when using default TTL
- Maintains proper authorization headers in both cases
This ensures backward compatibility and optimal request formatting.
tests/unit_test/test_unit_grant_token.py (4)
11-123: Excellent comprehensive test coverage for sync TTL functionality.The
TestGrantTokenTTLclass provides thorough coverage:
- Default TTL behavior testing
- Custom TTL values with proper mocking
- Validation of valid boundary values (1, 30, 300, 1800, 3600)
- Invalid value testing with appropriate error messages
- Complete workflow testing from API key to access token with proper authorization headers
The test structure is well-organized and uses proper mocking to isolate the unit tests.
125-182: Comprehensive async TTL functionality testing.The
TestAsyncGrantTokenTTLclass properly tests the async implementation:
- Uses
@pytest.mark.asynciodecorator correctly- Tests default and custom TTL behavior
- Validates error handling for invalid values
- Maintains consistency with sync test patterns
The async tests ensure both client types behave identically.
184-255: Thorough request body formatting validation.The
TestGrantTokenRequestBodyclass excellently tests:
- Proper inclusion of
ttl_secondsin request body when provided- Correct omission of JSON body when using default TTL
- Authorization header formatting verification
- Both sync and async request formatting
This ensures the API requests are properly formatted for the backend.
257-304: Comprehensive edge case and validation testing.The
TestGrantTokenEdgeCasesclass provides excellent coverage of:
- Boundary value testing (1 and 3600 seconds)
- Type validation for various invalid types (strings, floats, lists, dicts, booleans)
- Range validation for out-of-bounds values
- Proper error message verification
This thorough validation testing ensures robust input handling and clear error messages for developers.
2 participants
PR Summary: Add TTL Support to grant_token Endpoint
TL;DR
ttl_secondsparameter (1-3600 range, default 30) to both sync and asyncgrant_token()methods in the auth clients.Changes Made
Core Implementation
Modified
AuthRESTClient.grant_token()indeepgram/clients/auth/v1/client.pyttl_seconds: Optional[int] = Noneparameter{"ttl_seconds": value}Modified
AsyncAuthRESTClient.grant_token()indeepgram/clients/auth/v1/async_client.pyValidation Logic
ttl_secondsis an integer, explicitly excluding Python booleans (which are int subclass)ttl_secondsin JSON payload when parameter is providedExamples Updated
examples/auth/token/main.py: Added comprehensive TTL testing (default, custom, min, max values)examples/auth/async_token/main.py: Added async TTL testing scenariosexamples/auth/bearer_token_demo/main.py: Updated to demonstrate custom TTL in complete workflowNew Test Suite
tests/unit_test/test_unit_grant_token.py: Created dedicated test file with 14 comprehensive testsTestGrantTokenTTL: Basic TTL functionality and validationTestAsyncGrantTokenTTL: Async TTL functionalityTestGrantTokenRequestBody: Request body validationTestGrantTokenEdgeCases: Edge cases and boundary testingFiles Modified
Testing
Usage Examples
Basic Usage
Request Body
When
ttl_secondsis provided, the request includes:{ "ttl_seconds": 300 }Backward Compatibility
ttl_secondsparameter is optionalValidation
This implementation provides developers with fine-grained control over access token lifespans while maintaining full backward compatibility and robust error handling.
Types of changes
What types of changes does your code introduce to the community Python 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
Summary by CodeRabbit