Skip to content
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

v1.34.0 breaks the Google Ads API PHP users #514

Closed
fiboknacky opened this issue Jan 9, 2024 · 4 comments · Fixed by #515
Closed

v1.34.0 breaks the Google Ads API PHP users #514

fiboknacky opened this issue Jan 9, 2024 · 4 comments · Fixed by #515

Comments

@fiboknacky
Copy link

Copied from googleads/google-ads-php#981.

Environment details

  • OS: Linux 5.15.0-91-generic 101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64
  • PHP version: PHP 8.2.14
  • Package name and version: googe/auth v1.34.0

Steps to reproduce

After upgrading google/auth to v1.34.0, it seems to break the Google Ads API users because the developer-token header isn't sent anymore.
This header is sent as part of the middleware in this trait.

@bshaffer
Copy link
Contributor

bshaffer commented Jan 9, 2024

I'm looking into this - we took precautions to not break anyone in the latest google/gax and google/auth changes, which refactored how headers are sent in. While this behavior is definitely unexpected, it's most likely a result of those changes. Could you provide steps to reproduce the error in the bug you created?

@bshaffer
Copy link
Contributor

bshaffer commented Jan 9, 2024

I was able to identify that the issue actually happens in google/gax:1.26. I was able to deduce this because I did NOT receive the error while using google/auth:1.34 with google/gax:v1.25

Here are the changes as a result of this tag: v1.25.0...v1.26.0. I am looking into it now.

@bshaffer bshaffer transferred this issue from googleapis/google-auth-library-php Jan 9, 2024
@bshaffer
Copy link
Contributor

bshaffer commented Jan 9, 2024

Okay I figured it out - it has to do with this change, where we only call modifyClientOptions for V1 clients.

This was done because, since modifyClientOptions is private, and our new clients are final, it was assumed that there was no way for this method to be called. But as this method is being called by ads, this assumption is wrong (I believe the trait is being added in post-processing`, which allows this to happen for Ads specifically).

The fix is to remove the conditional here and call modifyClientOptions for all clients

@fiboknacky
Copy link
Author

Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants