ErrorListener does not support message array

[Maff-]

The Gitlab\HttpClient\Listener\ErrorListener will produce a Fatal error (Wrong parameters for ErrorException) when the Gitlab API returns a error message that contains an array instead of a string message. Offending line: 46

{"message":{"path":["has already been taken"]}}

This will mostly happen when an data validation error occurs. See Data validation and error reporting for possible response formats.

A simple solution could be to json encode the message when it's not a string.

Used versions: GitLab 7.4.0; GitLab API v3

[jubianchi]

I submitted those changes to the gitlab codebase. This is my fault, sorry :)

I'll try to submit a patch here.

[Maff-]

If you would be able to create a patch that would be great. But looking back through the commit history I'm not sure that this issue was ever not present, and certainly can't find something that you would have changed that causes this.

Note: I just started using thing lib, so I'm not sure it it was supposed to work before. Nor do I know if this a previous GitLab API responded differently.

[m4tthumphrey]

@jubianchi was saying that he'd made a change to the actual gitlab codebase, and the corresponding code in this repo has never been updated. I think anyway...

[Maff-]

That makes sense :).

Thanks for looking into this, but just let me know if I'll need to make a patch + pull request.

[j0k3r]

Any news about that issue ?

Still got some

Wrong parameters for Exception([string $exception [, long $code [, Exception $previous = NULL]]])

Shouldn't we just cast the $errorMessage ?

throw new RuntimeException((string) $errorMessage, $response->getStatusCode());

[Maff-]

I think simply casting it to a string will just throw a Array to string conversion notice. Not really a solution imo.

[jubianchi]

Hello folks!

I'm working on a patch right now, sorry for the delay I was really busy.
Hopefully I'll submit it today.

[m4tthumphrey]

Lots of ways of handling this...

• Convert the array to a JSON encoded string
• Implode the list of errors with a comma (or any other char really)
• Grab the first error (my personal preference)

@jubianchi @Maff- @j0k3r thoughts?

[j0k3r]

Implode the list of errors with a comma (or any other char really)

👍

So this error :

{
    "message": {
        "bio": [
            "is too long (maximum is 255 characters)"
        ],
        "path": [
            "has already been taken"
        ]
    }
}

should generate this exception message:

"bio" is too long (maximum is 255 characters), "path" has already been taken

I prefer to see all informations at once instead of getting the first error, fixin it, retryin, getting the second error (which I've not seen the first time since only the first error is reported), etc ..

[m4tthumphrey]

@j0k3r Yeh I agree. @jubianchi have you done anything on this yet? If not I'll do it now.. lemme know.

[m4tthumphrey]

I'm inpatient 😉

[j0k3r]

@m4tthumphrey thanks !

Could you tag a new release then?

[jubianchi]

@m4tthumphrey I was about to do the same thing you did in your patch: parse the JSON containing error messages and format them as a comma separated list of errors.

👍 thanks for the patch :)

[m4tthumphrey]

@j0k3r I'm working on a few clean up updates, once thats done I'll tag a new release.

[j0k3r]

@m4tthumphrey It seems to not be fully fixed, I just got :

[app] exception 'Gitlab\Exception\RuntimeException' with message '"0" Array' in /vendor/m4tthumphrey/php-gitlab-api/lib/Gitlab/HttpClient/Listener/ErrorListener.php:60

I guess parseMessage needs a recursive function to handle the $message.

I'm running Gitlab 7.8.2.

[m4tthumphrey]

@j0k3r Do you what the Gitlab error was that caused it?

[j0k3r]

Sadly not.

[m4tthumphrey]

What were you trying to do when you had it?

[j0k3r]

It's hard to say because we have integrated your Gitlab API inside an internal project that rely on Git to store some config file. This error was reported to us by a user that use this project, so hard to say. I could be a commit, a push or a merge request creation.

I can give you first lines of the stacktrace:

#0 /vendor/m4tthumphrey/php-gitlab-api/lib/Gitlab/HttpClient/HttpClient.php(177): Gitlab\HttpClient\Listener\ErrorListener->postSend(Object(Gitlab\HttpClient\Message\Request), Object(Gitlab\HttpClient\Message\Response)) 
#1 /vendor/m4tthumphrey/php-gitlab-api/lib/Gitlab/HttpClient/HttpClient.php(117): Gitlab\HttpClient\HttpClient->request('projects/351/me...', Array, 'POST', Array) 
#2 /vendor/m4tthumphrey/php-gitlab-api/lib/Gitlab/Api/AbstractApi.php(62): Gitlab\HttpClient\HttpClient->post('projects/351/me...', Array, Array) 

[m4tthumphrey]

Looks like merge request creation...

post('projects/351/me...'

I'll take a look.

[m4tthumphrey]

Should be sorted; there was an obvious bug with the 3rd param of the sprintf but that doesn't account for the field being "0" so have checked for the presence of a field name.

[j0k3r]

Sounds good to me 👍