CloudHSMv2 Integration #8532
CloudHSMv2 Integration #8532
Conversation
| if not max_results: | ||
| return tags, None | ||
|
|
||
| if next_token: |
There was a problem hiding this comment.
What is the reasoning behind manipulating the next_token?
There was a problem hiding this comment.
The token has to be converted into base64 so without it, we get something like eyJwYXJhbWV0ZXJDaGVja3N1bSI6IDQyMzg4OTQxMTIsICJ1bmlxdWVBdHRyaWJ1dGVzIjogIlByb2plY3QifQ instead of eyJwYXJhbWV0ZXJDaGVja3N1bSI6IDQyMzg4OTQxMTIsICJ1bmlxdWVBdHRyaWJ1dGVzIjogIlByb2plY3QifQ==. Is this not the right approach?
There was a problem hiding this comment.
That explains what it does - I wanted to know why 🙂
The nextToken that AWS returns is usually a random string, and the user should not care about the exact format of it. So my question was more: why do we need to manipulate the token, and can we not use the token that the Paginator returns?
If we don't have to manipulate the token, then we can rip this all out and replace it with the @paginate decorator instead, which would be much nicer (IMHO).
If there is a good reason we must manipulate the token, then that's fine as well - I would just want to know why.
|
|
||
| clusters = sorted(clusters, key=lambda x: x.create_timestamp) | ||
|
|
||
| if not max_results: |
There was a problem hiding this comment.
This doesn't look right - even if we don't have max_results specified, we may have a next_token that we should honor.
Can we use the @paginate-decorator here instead?
Resolves #8571