-
-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google TTS no longer works. #442
Comments
Okay and we've done some bisecting and found that images made with version 3.1.0 work and it's just the 5.0.3 image that is broken. |
Thanks for reporting! I think there was a change related to the way certain kinds of data are represented. It should be possible to find this commit and maybe make it apply only to certain APIs. On the other hand, maybe there is an updated version of TTS available that would work with these changes, too. |
I had a brief look for updates and didn't see any (but the google docs are pretty poor for finding this kind of info). It seems it's having trouble when checking the base64 response, but as it doesn't decode it and leaves that to me the user such a check seems kind of worthless? Like I have to check the result when converting it to bytes anyway - if this client won't decode the base64 for me why check it 🤷♂️ |
Okay I've done a bit of bisecting and can confirm the issue isn't present in 4.x and was introduced in 5.x. We're rolling back for now but I'm willing to help PR a change for this if it could expedite things, I just need pointing in the right direction 👀 |
I recommend to use the local source of the crate in question to make it editable, and compare the working version and the non-working one. They will be close enough to make that possible. From there a local fix can be conceived and tested, and with it I can certainly be a guide to get a more permanent fix done, by some means supported by the generator. After all, per-API overrides are possible, should the fix be very specific. Please also note that generally there should be a better way than using these crates, it's astonishing that Google doesn't support Rust officially yet. |
Think I'm facing something similar with the secret manager secret access endpoint. Interesting thing I've found so far (haven't figured out WHY yet) is that if you handle the JsonDecodeError, take the payload and pass it thru serde_json::from_str it will decode just fine. Must be some encoding parameters somewhere. |
Ahha. It seems like the payload data was previously Currently trying to find a reference somewhere for what encoding variant google uses. |
I can see some reference online (eg here https://stackoverflow.com/questions/28100601/decode-url-safe-base64-in-javascript-browser-side) that some APIs are URL safe which might indicate that an API-by-API choice is necessary for how to decode these values... grumble. If I find more I will post here. |
Byron#442 flags an issue where some APIs respond with non-valid base64 bytes values for the "URL safe" flavor of configuration. This adds support for a "standard" wrapper adjacent to the URL safe one with the intention of finding a way to flag which structures should use which configuration.
It doesn't matter what the request is we get responses like this:
A snippet of the code, the error message comes from the result of awaiting
.doit()
.The text was updated successfully, but these errors were encountered: