I’m not sure if this is by design, but thought I’d ask.
If you throw an exception within a typical void returning Delete method then the error is always returned as an internal server error, even if you wanted to throw a forbidden exception for example.
I’ve just added an integration test showing that’s not the case:
It may be linked to me using IReturnVoid rather than *Response?
Using IReturnVoid works as well:
I’d look at the raw HTTP Response to see if you can find out what the cause of the 500 Error is.
With me using protobuf it’s a bit more difficult to view the raw response, the headers I receive are:
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Origin: *
Content-Type: application/x-protobuf
Date: Fri, 12 Oct 2018 14:59:33 GMT
Set-Cookie: ss-id=FttbMHxxD4MhJYaIRGq7; path=/; samesite=lax; httponly
Set-Cookie: ss-pid=baOnHwbr3ug456GYYBL2; expires=Tue, 12 Oct 2038 14:59:33 GMT; path=/; samesite=lax; httponly
Transfer-Encoding: chunked
Vary: Accept
X-Powered-By: ServiceStack/5.40 NetCore/OSX
The data I can glean from the response is:
InternalServerErrorùServiceStack.HttpError: Failed to execute!
at ***.Service.Delete(DeleteUser request) in *****:line 243[DeleteUser: 10/12/2018 14:59:34]:
[REQUEST: {id:3}]
ServiceStack.HttpError: ServiceStack.HttpError: Failed to execute!
at ***.Service.Delete(DeleteUser request) in ***:line 243
at ***.Service.Delete(DeleteUser request) in ***:line 285
at lambda_method(Closure , Object , Object )
at ServiceStack.Host.ServiceExec1.<>c__DisplayClass3_0.<CreateExecFn>b__0(Object service, Object request) at ServiceStack.Host.ServiceRunner1.ExecuteAsync(IRequest req, Object instance, TRequest requestDto)
It’s all quite odd, doing some further testing, I’m seeing the 500 errors on PUT and DELETE, however GET and POST work fine.
I’ve added ProtoBufServiceClient to the ExceptionHandlingTests and resolved an issue with trying to access the length of a Stream in this commit which may or may not resolve your issue.
This change is available from v5.4.1 that’s now available on MyGet.
Both the ExceptionHandlingTests.cs and ExceptionHandling2Tests.cs now include the ProtoBufServiceClient in its Exception handling tests and are now passing without issue. In order to investigate any other issue, I’ll need a stand-alone repro (using ServiceStack libraries, i.e. ProtoBufServiceClient not 3rd party js libs) I can run locally to repro the issue.
Awesome, 5.4.1 fixes the issue. Thank you for the wonderful support as always!