Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1074989

Summary: REST API returns HTTP code 500 even though it is obviously not a server error and rather incorrect request
Product: [Retired] JBoss BRMS Platform 6 Reporter: Petr Široký <psiroky>
Component: Business CentralAssignee: Shelly McGowan <smcgowan>
Status: CLOSED EOL QA Contact: Jiri Locker <jlocker>
Severity: medium Docs Contact:
Priority: high    
Version: 6.0.1CC: jlocker, kverlaen
Target Milestone: ER3   
Target Release: 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 20:09:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Server log excerpt
none
Response send to the client
none
Full server log none

Description Petr Široký 2014-03-11 10:36:42 UTC 
Description of problem:
The REST API for Business Central (and probably also for the jBPM runtime stuff - not sure there though) returns HTTP 500 Internal Server Error even for cases when its obviously _not_ a server error, but rather error in the request.

For example when you send a request to clone a git repo and you specify name that already exists, the server will return 500 Internal Server Error. I think this is not correct as in fact the reason for the failure is not the server error, but rather incorrect request.

I am not 100% sure what status code should be returned, but it might be useful to follow some guidelines. Following is for example how Twitter API handles the error codes: https://dev.twitter.com/docs/error-codes-responses


Version-Release number of selected component (if applicable):
6.0.1-ER2

How to reproduce:
1. Send request to `http://localhost:8080/business-central/rest/repositories` with following content:
{"name":"jbpm-playground", "description":"", "userName":"", "password":"", "requestType":"clone", "gitURL":"git:droolsjbpm/jbpm-playground.git"}

2. Send the same request again.

Actual result:
The server returns HTTP 500 Internal Server Error.

Expected result:
Some other HTTP status code, certainly not 500.
Comment 1 Marco Rietveld 2014-03-14 10:58:33 UTC 
Hi Petr, thanks for catching this. 

Could you _attach_ a full server.log? (Please do not paste it in a comment! :)
Comment 2 Petr Široký 2014-03-14 11:07:02 UTC 
Created attachment 874324 [details]
Server log excerpt
Comment 3 Petr Široký 2014-03-14 11:10:20 UTC 
Created attachment 874325 [details]
Response send to the client

Marco, I have attached the server log excerpt and also the response. They are basically the same, but maybe they could both be useful.
Comment 4 Petr Široký 2014-03-14 11:12:10 UTC 
Created attachment 874326 [details]
Full server log

Now I see you actually wanted full server log, so attaching also that.
Comment 5 Marco Rietveld 2014-03-17 17:04:25 UTC 
Petr, thanks. Actually the HTTP status that should be returned here should be 202, because it should be an asynchronous request. See BZ 1077305 for more info. 

Thanks very much for attaching the logs!
Comment 6 Marco Rietveld 2014-03-17 17:06:06 UTC 
FYI, re HTTP statuses, I usually look at RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html) to determine the correct status to use, but the twitter URL is very helpful. Thanks!
Comment 7 Petr Široký 2014-03-17 17:43:51 UTC 
This issue is basically a subset of BZ 1077305. So once that one is resolved this one should be too. The main problem is that the operation should be asynchronous and not synchronous.
Comment 8 Marco Rietveld 2014-05-29 20:56:41 UTC 
This has been fixed on master.
Comment 9 Marco Rietveld 2014-10-23 20:11:37 UTC 
Does this issue specifically refer to BPMS 6.0.x, or would it be okay to move the version to BPMS 6.1 and set it to modified, since it's been fixed in BPMS 6.1?
Comment 10 Petr Široký 2014-10-24 08:23:37 UTC 
I believe it has been already moved to BPMS 6.1 (see the flag jboss‑brms‑6.1.0), so it should be OK to change the state to modified. In case there would be a patch requested for 6.0.x, we can always cone this BZ into new one.
Comment 11 Jiri Locker 2014-11-18 18:40:28 UTC 
I have hit this issue too. I hope it is now fixed in community and I am adding example requests for veryfing the fix:

1. Getting organizational unit that does not exist
curl -i -u '<user>:<password>' -H 'Content-Type: application/json' -X GET 'http://localhost:8080/business-central/rest/organizationalunits/<org_unit>'

2. Getting repository that does not exist
curl -i -u '<user>:<password>' -H 'Content-Type: application/json' -X GET 'http://localhost:8080/business-central/rest/organizationalunits/<repository>'
Comment 12 Marco Rietveld 2014-11-21 14:09:16 UTC 
Fixed. Commits: 

6.2.x: 
https://github.com/droolsjbpm/guvnor/commit/6914081c

master: 
https://github.com/droolsjbpm/guvnor/commit/b88c2f0f
Comment 13 Petr Široký 2014-12-17 22:00:06 UTC 
Verified in 6.1.0.ER3. The POST/PUT/DELETE operations are now asynchronous (returning job request info). For GET and case where OU/repo does not exist, "404 Not Found" is returned.