phpro / api-problem Goto Github PK

Bug Report

Summary

Some exceptions return a code getCode() - that are non-numeric, but a string instead. For example an Illuminate\Database\QueryException in a Laravel application had a code "42S02" (note the "S" in the middle). Passing this into the Phpro\ApiProblem\Http\ExceptionApiProblem for rendering results in a further exception being thrown:

Phpro\ApiProblem\Http\HttpApiProblem::__construct(): Argument #1 ($statusCode) must be of type int, string given, called in /.../vendor/phpro/api-problem/src/Http/ExceptionApiProblem.php on line 26 {"exception":"[object] (TypeError(code: 0): Phpro\ApiProblem\Http\HttpApiProblem::__construct(): Argument #1 ($statusCode) must be of type int, string given, called in /.../vendor/phpro/api-problem/src/Http/ExceptionApiProblem.php on line 26 at /.../vendor/phpro/api-problem/src/Http/HttpApiProblem.php:60)

Current behaviour

How to reproduce

This is hard to reproduce outside of Laravel. You cannot create a Illuminate\Database\QueryException exception with a non-numeric code directly, but the framework can. Within laravel, accessing a table that does not exist through the database builder generates an SQL error with details:

+errorInfo: array:3 [
      0 => "42S02"
      1 => 1146
      2 => "Table 'print_trail_core.jobs' doesn't exist"
    ]

which is passed into a PDOException exception, which in turn is passed into an Illuminate\Database\QueryException exception. Fetching the code for that gives "42S02" and that is a problem when that exception is passed to Phpro\ApiProblem\Http\ExceptionApiProblem.

The constructor checks if the code is in the range 400 to 599 and uses it directly if it is, and (bizarrely) it is:

>>> $exceptionCode = "42S02"
=> "42S02"
>>> $statusCode = $exceptionCode >= 400 && $exceptionCode <= 599 ? $exceptionCode : 500
=> "42S02"

If I cast the status code to an int, then it comes out as 42 (again, not sure why - it should be a 500 surely?) but it does not throw a second exception.

Expected behaviour

An exception passed to Phpro\ApiProblem\Http\ExceptionApiProblem that returns a non-numeric getStatus() (and they do exist) should result in a code of 500, and not throw another exception complaining about the non-numeric status code that it tries to use to pass to the parent constructor (class Phpro\ApiProblem\Http\HttpApiProblem).

I didn't realise this is very much just for Symfony until trying to use it, and realised it references a lot of Symfony interfaces and classes. None of these are listed in the composer dependencies.

Nice idea otherwise. A generic RFC-7807 payload construction package is sorely missing.

Please add a new tag v1.3.0 to the current master branch because in v1.2.0 BadRequestProblem and ConflictProblem are not available. Thanks!

ValidationApiProblem::TYPE_SYMFONY_VIOLATIONS = 'https://symfony.com/errors/validation' leads to the 404 page.

Feature Request

Summary

An additional interface with some getters for the RFC specific field members (chapter 3.1) would be very nice to have.

I have often mistyped on those fields. Some interface which let a developer implement specific methods to be strict about it would be great.

Just of the top of my head...

interface StrictApiProblemInterface
{
    public function getType(): ?string
    public function getTitle(): string
    public function getStatus(): ?int
    public function getDetail(): ?string
    public function getExtensions(): array
}