Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-27152

Show REST exceptions in the Symfony profiler

    Details

      Description

      When an REST exception occurs, it is not shown in the Symfony profiler. It is easily reproduced by requesting a content that doesn't exist, like /api/ezp/v2/content/objects/77777. The profiler for the failing request will have 0 exceptions reported, while one did occur.

      REST exceptions should be listed like any other exception.

        Issue Links

          Activity

          Nuno Oliveira (Inactive) created issue -
          Nuno Oliveira (Inactive) made changes -
          Field Original Value New Value
          Component/s Platform > Profiler > Full stack [ 13349 ]
          Nuno Oliveira (Inactive) made changes -
          Link This issue relates to CS-6080 [ CS-6080 ]
          Nuno Oliveira (Inactive) made changes -
          Link This issue relates to EZP-24853 [ EZP-24853 ]
          Nuno Oliveira (Inactive) made changes -
          Status Open [ 1 ] Confirmed [ 10037 ]
          Nuno Oliveira (Inactive) made changes -
          Description When debugging new components (e.g. a new FieldType), it is not possible to see the full stack trace of the actual error, only the latest trace. The problem is that the exception is caught in the ez rest code and retrown. When the code is retrown the earlier stack trace is no longer available. When debugging new components (e.g. a new FieldType), it is not possible to see the full stack trace of the actual error, only the latest trace. The problem is that the exception is caught in the ez rest code and retrown. When the code is retrown the earlier stack trace is no longer available.

          Please improve that behavior, so that the whole stack trace is available for inspection.
          André Rømcke made changes -
          Status Confirmed [ 10037 ] InputQ [ 10001 ]
          Damien Pobel (Inactive) made changes -
          Assignee Bertrand Dunogier [ bertrand.dunogier@ez.no ]
          Hide
          Bertrand Dunogier added a comment -

          I don't understand what stacktrace is expected for this particular error. This error says that the FieldTypeHashGenerator can't generate a hash from an object. It is meant to serialize the values returned by the fromHash() method from the FieldType API, that is not supposed to return objects. The Exception described in this issue isn't bubbling up from the FieldType. It is thrown in a switch/case's default statement, so there is no "previous" exception.

          I might be missing something, and maybe it tries to serialize an exception, but I don't really understand how that would happen: if an exception is thrown, it will bubble up until it is caught, and will interrupt this switch case. As mentioned, REST exceptions include the whole exception stack recursively since v1.5.

          Show
          Bertrand Dunogier added a comment - I don't understand what stacktrace is expected for this particular error. This error says that the FieldTypeHashGenerator  can't generate a hash from an object. It is meant to serialize the values returned by the fromHash() method from the FieldType API, that is not supposed to return objects. The Exception described in this issue isn't bubbling up from the FieldType. It is thrown in a switch/case's default statement, so there is no "previous" exception. I might be missing something, and maybe it tries to serialize an exception, but I don't really understand how that would happen: if an exception is thrown , it will bubble up until it is caught, and will interrupt this switch case. As mentioned, REST exceptions include the whole exception stack recursively since v1.5.
          Bertrand Dunogier made changes -
          Status InputQ [ 10001 ] Backlog [ 10000 ]
          Hide
          Bertrand Dunogier added a comment - - edited

          While there is no earlier exception to show as far as I can tell, the exception is indeed not showing up in the symfony profiler. This should be improved. I'll rephrase the enhancement request (done).

          Show
          Bertrand Dunogier added a comment - - edited While there is no earlier exception to show as far as I can tell, the exception is indeed not showing up in the symfony profiler. This should be improved. I'll rephrase the enhancement request (done).
          Bertrand Dunogier made changes -
          Description When debugging new components (e.g. a new FieldType), it is not possible to see the full stack trace of the actual error, only the latest trace. The problem is that the exception is caught in the ez rest code and retrown. When the code is retrown the earlier stack trace is no longer available.

          Please improve that behavior, so that the whole stack trace is available for inspection.
          When an REST exception occurs, it is not shown in the Symfony profiler. It is easily reproduced by requesting a content that doesn't exist, like {{/api/ezp/v2/content/objects/77777}}. The profiler for the failing request will have 0 exceptions reported, while one did occur.

          REST exceptions should be listed like any other exception.
          Bertrand Dunogier made changes -
          Summary Enhance REST output when debugging new components Show REST exceptions in the Symfony profiler
          Bertrand Dunogier made changes -
          Status Backlog [ 10000 ] Development [ 3 ]
          Bertrand Dunogier made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Hide
          Bertrand Dunogier added a comment -

          Opened https://github.com/ezsystems/ezpublish-kernel/pull/1968 with a fix that prevents the exceptions from being concealed in the profiler.

          Show
          Bertrand Dunogier added a comment - Opened https://github.com/ezsystems/ezpublish-kernel/pull/1968 with a fix that prevents the exceptions from being concealed in the profiler.
          Bertrand Dunogier made changes -
          Status Development Review [ 10006 ] Backlog [ 10000 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 103303 ] EZEE Development Workflow [ 108148 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Confirmed Confirmed
          9m 49s 1 nuno.oliveira@ez.no 28/Mar/17 6:12 PM
          Confirmed Confirmed InputQ InputQ
          33m 47s 1 André Rømcke 28/Mar/17 6:46 PM
          InputQ InputQ Backlog Backlog
          26d 20h 2m 1 Bertrand Dunogier 24/Apr/17 2:48 PM
          Backlog Backlog Development Development
          20h 24m 1 Bertrand Dunogier 25/Apr/17 11:13 AM
          Development Development Development Review Development Review
          3s 1 Bertrand Dunogier 25/Apr/17 11:13 AM
          Development Review Development Review Backlog Backlog
          71d 23h 17m 1 Bertrand Dunogier 06/Jul/17 10:31 AM

            People

            • Assignee:
              Bertrand Dunogier
              Reporter:
              Nuno Oliveira (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: