FriendsOfSymfony / FOSRestBundle

This Bundle provides various tools to rapidly develop RESTful API's with Symfony
http://symfony.com/doc/master/bundles/FOSRestBundle/index.html
MIT License
2.79k stars 704 forks source link

Struggling to upgrade from 2.X to 3.X #2267

Closed fliespl closed 3 years ago

fliespl commented 4 years ago

Hey, I am working on updating from version 2.X to 3.X, but unfortunately there are a few things that doesn't work as expected - i.e. exception handling (mapping exceptions to codes).

I have read upgrading document, but it doesn't mention anything I can do to change.

I have a controller like this:

public function allAction() { throw new Symfony\Component\Routing\Exception\ResourceNotFoundException('abc'); }

Configuration like that:

    exception:
        codes:
            'Symfony\Component\Routing\Exception\ResourceNotFoundException': 404
            'Doctrine\ORM\OptimisticLockException': 409
            'Symfony\Component\Security\Core\Exception\InsufficientAuthenticationException': 401
            'Symfony\Component\HttpKernel\Exception\UnauthorizedHttpException': 401
            'Symfony\Component\HttpKernel\Exception\BadRequestHttpException': 400
        messages:
            'Symfony\Component\Routing\Exception\ResourceNotFoundException': true
            'Symfony\Component\HttpKernel\Exception\BadRequestHttpException': true
            'Symfony\Component\HttpKernel\Exception\UnauthorizedHttpException': true
            'Symfony\Component\HttpKernel\Exception\NotFoundHttpException': true
            'AppBundle\Exception\TranslatableHttpException': true

In version 2.x it rendered as:

{
  "code": 404,
  "message": "abc"
}

In 3.X it ends up as 500 in json.

I am aware that a lot of stuff like exception handling was removed, but are there any instructions that might help to restore this functionality?

I have looked through other tickets, but nothing seems to work.

Any help would be appreciated.

xabbuh commented 4 years ago

Do you see anything in the logs? Otherwise having an example application that allows to reproduce your issue might help.

fliespl commented 4 years ago

Thanks :)

I have noticed one deprecation and changed config twig.exception_controller to null.

It looks better, but still 500 (instead of 404), but at least response body is closer to what it was (code + message instead of full exception with trace).

Gonna dig deeper and provide full example if I can't get to the bottom of this.

fliespl commented 4 years ago

Okay, so I have given it in deep look.

\FOS\RestBundle\ErrorRenderer\SerializerErrorRenderer gets called corretly, but FlattenException call returns exception with statusCode = 500 which then ends up being as response status code (cause it's not either one of HttpExceptionInterface etc).

https://ss.codeone.pl/ss-2020-09-03_10-16-27-1599120987.png

I think that \FOS\RestBundle\ErrorRenderer\SerializerErrorRenderer::render method should also map classes to status codes after flattening to match it from 2.X.

fliespl commented 4 years ago

Figured it out after researching.

map_exception_codes: true was missing (it's one of configs inside exception).

Previously it worked based on if codes array was empty - currently it also requires this switch.

solverat commented 3 years ago

tldr; I struggled upgrading from 2 to 3 like several others here regarding non-formatted exceptions.

In my case, setting twig.exception_controller to null fixed it:

twig:
    exception_controller: null

@fliespl If possible, you could implement theSymfony\Component\HttpKernel\Exception\HttpExceptionInterface in your exception like in the example below (then you'll have your dynamic status codes again).

<?php

namespace AppBundle\Exception;

use Symfony\Component\HttpKernel\Exception\HttpExceptionInterface;

class ApiException extends \Exception implements HttpExceptionInterface
{
    public function getStatusCode()
    {
        return YOUR_CODE;
    }

    public function getHeaders()
    {
        return [];
    }
}
fliespl commented 3 years ago

Thanks @solverat, but as pointed above - I was missing map_exception_codes setting, which changed it's behaviour between v2 and v3.

GuilhemN commented 3 years ago

Closing as the initial issue was resolved.