- 
                Notifications
    You must be signed in to change notification settings 
- Fork 5
Adds HTTP Client Adapter #2
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
base: trunk
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In testing out implementing the PHP AI Client package in one of our plugins, ran into an issue where our E2E tests all fail. The issue for us is we install a test plugin during our E2E tests that hooks into pre_http_request and returns mocked responses (so we don't have to hit actual APIs every time we run tests).
This doesn't work when requests are sent by the PHP AI Client package as it doesn't use the WordPress HTTP API. I had thought that this PR might solve that but still getting the same problems while testing this. Apologies if I'm missing something obvious here but are there additional steps required to ensure this adapter is used?
| @dkotter You're on the bleeding edge 😆 This is all early WIP. This adapter is indeed supposed to fix the problem you mentioned. It's not a bug in the PHP AI Client SDK since it is WordPress agnostic, but that kind of thing is exactly why this package exists. As far as I can tell, this PR implements the adapter but doesn't use it yet, but that will be added. Apologies for the confusion, but it might be a bit too early to test this package in particular as it's not meant to be usable just yet. That'll hopefully be different in a week or so :) | 
| 
 Correct, not calling that out as a bug, just hadn't thought of that until I opened a PR and saw all our tests fail 😭 
 No worries, sounds good. Realize I'm jumping in early here, was just trying to help do some testing on this PR to help get it merged but realize there's lots of things still in progress across all these work streams | 
| @felixarntz This is back to you for review! A couple things to note: First, I updated the class names and such to reflect PSR-4, and I updated some types stuff to pass PHPStan. We'll simply have more use of  Second, I added a  Third, I added the  What do you think? 😄 | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JasonTheAdams Overall, this all makes sense to me. A bit of feedback regarding the WordPress specific implementation.
| // TODO: Update to use PHP AI Client exceptions. | ||
| throw new \Exception( | ||
| $response->get_error_message(), // phpcs:ignore WordPress.Security.EscapeOutput.ExceptionNotEscaped | ||
| $response->get_error_code() ? (int) $response->get_error_code() : 0 | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't work in 99% of scenarios, WordPress error codes are almost always strings with text.
What I would suggest is:
- Either introduce something like a WP_Error_Exceptionthat allows to maintain the WordPress error codes too, via an additional property.
- Or rely on one of the HTTP request/response specific exceptions that are being added as part of Implement Exception Hierarchy For Better Error Handling php-ai-client#78.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's see if we can get the exception PR done soon and I'll use that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally resolved in de7de24!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comment here is still relevant I think: What I'm saying is it doesn't make sense to interpret a WP_Error's error code as an integer, since it's meant to be a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per the above, I think we should simply remove this line. There's no reasonable way to maintain the WordPress error code within the exception, unless we come up with a new exception class that can also store a string-shape as error code. But that's overkill IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JasonTheAdams This looks excellent, great work!
A few questions, and two small things to ideally address before merge.
| // PSR-17 factories - Nyholm's Psr17Factory implements all of them. | ||
| $psr17_factories = array( | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mostly a question for my own understanding: Why do we need this? Why wouldn't we be able to only inject our WordPress HTTP Client and leave the rest?
| return array( | ||
| array( | ||
| 'class' => Psr17Factory::class, | ||
| 'condition' => Psr17Factory::class, | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the condition field for? And why is it simply the same as class?
| * @since n.e.x.t | ||
| * @return void | ||
| */ | ||
| public static function init() { | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this method is the entry point to all this? As in: Consuming code will need to call this static method to wire up our WordPress HTTP Client with the PHP AI Client SDK, and nothing else, right?
| $message = sprintf( | ||
| 'Network error occurred while sending request to %s: %s', | ||
| $url, | ||
| $response->get_error_message() | ||
| ); | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor suggestion: Include the request method here as well.
| $message = sprintf( | |
| 'Network error occurred while sending request to %s: %s', | |
| $url, | |
| $response->get_error_message() | |
| ); | |
| $message = sprintf( | |
| 'Network error occurred while sending %s request to %s: %s', | |
| $request->getMethod(), | |
| $url, | |
| $response->get_error_message() | |
| ); | 
| // TODO: Update to use PHP AI Client exceptions. | ||
| throw new \Exception( | ||
| $response->get_error_message(), // phpcs:ignore WordPress.Security.EscapeOutput.ExceptionNotEscaped | ||
| $response->get_error_code() ? (int) $response->get_error_code() : 0 | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per the above, I think we should simply remove this line. There's no reasonable way to maintain the WordPress error code within the exception, unless we come up with a new exception class that can also store a string-shape as error code. But that's overkill IMO.
This PR will add the Client Adapter so that the PHP AI Client uses the WP functions to fulfill requests.