View Issue Details

IDProjectCategoryView StatusLast Update
0025384mantisbtapi restpublic2019-01-31 02:57
Reporterobmsch Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
Product Version2.19.0 
Summary0025384: Get issues: Inconsistent error handling/reporting
Description

The different flavors of 'Get Issues' with restrictions (issue_id, project_id, filter_id) handle missing entities inconsistent.

  1. issue_id=number:
    404, 'Issue #number not found'
  2. project_id=number:
    404, 'Project "number" doesn't exist'
  3. filter_id=number:
    500, 'Internal Server Error'
  4. filter_id=string:
    200, 'OK' with Content {"issues":{"status_code":404,"fault_string":"Unknown filter 'string'"}}
TagsNo tags attached.

Relationships

related to 0025406 confirmed Get Filter API should return errors when filter is not found or filter id invalid 

Activities

obmsch

obmsch

2019-01-25 14:13

reporter   ~0061300

To get at least rid of the 500 in (3.) the call

if( is_numeric( $p_filter_id ) ) {
        $t_filter = filter_get( $p_filter_id );

in 'mc_filter_get_issues' (api\soap\mc_filter_api.php) should be replaced with

if( is_numeric( $p_filter_id ) ) {
        $t_filter = filter_get( $p_filter_id, null );

Then (3.) is put on par with (4.) and returns
200, 'OK' with Content {"issues":{"status_code":404,"fault_string":"Unknown filter 'number'"}}

atrol

atrol

2019-01-30 15:05

developer   ~0061335

As I am no specialist in designing REST API's, @vboctor what @obmsch wrote at 0025384:0061300 is certainly better than what we have now, and is the same way how the similar function mc_filter_get_issue_headers deals with it.

I am note complete sure if HTTP status 200, 'OK' in combination with some more status information in response is the right way to deal with it, or if HTTP code 404 is also the right one for cases 3. and 4.

vboctor

vboctor

2019-01-31 01:16

manager   ~0061343

Thanks @obmsch for reporting the bug. The correct behavior is as follows:

  1. If specified filter id is numeric but doesn't exist, then response code should be 404 Filter number 1234 not found (similar to 1 and 2).
  2. If specified filter id is invalid (e.g. a string), then response code should be 400 Invalid filter id 'abcd'. --- 400 == bad request representing a client error.
  3. The content of the response returned should be consistent for all cases (e.g. project not found, filter not found, issue not found, etc). For example, project not found returns the http response with code + string, but the body is empty and doesn't contain the json referred to in case 4.

Often the differences in behaviors occur due:

  1. Internal Server Error is often caused by an exception is not handled properly or an error not triggered that is not an exception..
  2. The case of 200 + error json is problem caused by some generic handler, which is not the right behavior. Don't remember the exact cases.

So in short all errors should behave like case 1 and 2 in 0025384:0061300

The same kind of behaviors should apply to other APIs, e.g. Getting a filter by id - which currently returns success and empty array when filter id is not found or is invalid. But this can be a different bug.

Pull Requests are welcome, if not, I will try to get to around to fixing this at some point.

vboctor

vboctor

2019-01-31 01:28

manager   ~0061344

I have reported bug 0025406 for get filter by id error handling and linked it to this issue.

atrol

atrol

2019-01-31 02:57

developer   ~0061346

If specified filter id is invalid (e.g. a string)

@vboctor strings are not invalid in general. There are some hardcoded allowed values, see function filter_standard_get.

Of course, it's a bit inconsistent as in function mc_filter_get_issue_headers is no special treatment of non numeric id's.