Implement an ErrorTransport #1529
Conversation
|
Once this is done, it'll be possible to make FOSElasticaBundle handle non-200 errors from ruflin/Elastica and test that behavior properly |
|
@jandom Thanks for opening this, will try to have a look soon. Could you add a changelog entry and a bit more details to the PR description on why this is needed and how it works. |
|
@ruflin done – updated this PR text and the changelog |
|
Thanks for PR. What about codes other than 403? |
|
@Destroy666x agreed completely, however that would require a more generic class for mocking different types of codes – do you want to contribute to the PR? |
|
Unfortunately not in the nearest future |
|
@ruflin is anything else needed to merge this PR? |
|
@ruflin updated the PR and made the NullTransport more generic and testable @Destroy666x added the support for non-403 error codes that you've requested Matching PR FOSElasticaBundle in https://github.com/FriendsOfSymfony/FOSElasticaBundle/pull/1465/files |
| @@ -93,6 +94,7 @@ public function exec(Request $request, array $params) | |||
| [ | |||
| 'request_header' => $request->getMethod(), | |||
| 'http_code' => $res->getStatusCode(), | |||
| 'body' => $responseBody, | |||
There was a problem hiding this comment.
I'm looking at this line and wondering if it could have any other side effects. Thoughts?
There was a problem hiding this comment.
@ruflin unlikely but your heart is in the right place: nothing apart from tests was accessing the array passed to 'setTransportInfo'
When using AwsAuthV4 transport, it is possible that the user provides incorrect credentials. This means that the Guzzle client will get a 403 from AWS. By default Guzzle silently ignores all exceptions and stores them in `$response->setTransferInfo()` This feature allows a downstream client/library to handle them however. Currently, FOSElastica does nothing to process 403 or other errors that come back from ruflin/Elastica (transferInfo is never used). This causes a problem because 403 are silently ignored and the progress bar appears to be moving unhindered ;-) This PR is a pre-requisite for unit tests that will accompany this fix on FOSElastica # Conflicts: # test/Elastica/Transport/NullTransportTest.php
When using AwsAuthV4 transport, it is possible that the user provides incorrect credentials.
This means that the Guzzle client will get a 403 from AWS.
By default Guzzle silently ignores all exceptions and stores them in
$response->setTransferInfo()This feature allows a downstream client/library to handle them however.
Currently, FOSElastica does nothing to process 403 or other errors that come back from ruflin/Elastica (transferInfo is never used).
This causes a problem because 403 are silently ignored and the progress bar appears to be moving unhindered ;-)
This PR is a pre-requisite for unit tests that will accompany this fix on FOSElastica