chore: remove next token from list_caches and list_signing_keys #173
Conversation
Remove the next_token argument from list_caches and list_signing_keys. It isn't used by the back end and clutters the function signature. Add a delete_cache to an integration test that was missing one. The tests may still leak caches if the tests fail before getting to the delete cache statement at the end. More comprehensive protection will follow.
| let request = Request::new(ListCachesRequest { | ||
| next_token: next_token.unwrap_or_default(), | ||
| next_token: String::new(), |
There was a problem hiding this comment.
Can we just omit this line? Or do we need to explicitly pass a default?
There was a problem hiding this comment.
The rust struct requires a string here, and it's not Optional, so we have to pass something :) idk if there is some kind of built-in Tonic "default" thing to use here as oppose to String.new though. @kvcache ?
There was a problem hiding this comment.
We're just using an empty string in the other SDKs.
| let request = Request::new(ListSigningKeysRequest { | ||
| next_token: next_token.unwrap_or_default().to_string(), | ||
| next_token: String::new(), |
There was a problem hiding this comment.
Same question here re: default
| let request = Request::new(ListCachesRequest { | ||
| next_token: next_token.unwrap_or_default(), | ||
| next_token: String::new(), |
There was a problem hiding this comment.
The rust struct requires a string here, and it's not Optional, so we have to pass something :) idk if there is some kind of built-in Tonic "default" thing to use here as oppose to String.new though. @kvcache ?
Remove the next_token argument from list_caches and list_signing_keys. It isn't used by the back end and clutters the function signature.
Add a delete_cache to an integration test that was missing one. The tests may still leak caches if the tests fail before getting to the delete cache statement at the end. More comprehensive protection will follow.