Error hooks non called in some error situations

#1

Hi, I have subscribed to appHost.ServiceExceptionHandlers , appHost.UncaughtExceptionHandlers and public override void OnExceptionTypeFilter …

However there are situations where none of these methods are called ,
Specifically , if I have a service that requires an integer as input and, as a rest request , a letter is passed ,

http://locahost/v1/rights/notanumber

I get a 400 and such a response as shown below

{
ResponseStatus: {
ErrorCode: “RequestBindingException”
Message: “Unable to bind request”
StackTrace: " at ServiceStack.Host.RestHandler.CreateRequest(IRequest httpReq, IRestPath restPath) at ServiceStack.Host.RestHandler.ProcessRequestAsync(IRequest httpReq, IResponse httpRes, String operationName)"
}-
}

but none of the above mentioned hooks are called. Is it a bug or the intended behaviour ?

#2

Sorry, I was not correct … actually in the case I’ve shown above the UncaughtExceptionHandlers is called.

The situation where none of the above handlers is called is when I add a validator

container.Register<ServiceStack.FluentValidation.IValidator>(
new Hello2ValidatorCollection());

and the request does not match the validator requirement

#3

@sabbadin12 Would you be able to provide a small project that reproduces the problem? This would make it a lot quicker to track down what might be causing this problem for you.

#4

how you suggest to do it ? it doesn’t seem I can upload a zip here

#5

Create a Github repository, share via Dropbox or another file hosting provider?

#6

Actually same use case using soap format will not pass through

either.

In other word, if the soap message contains a property that should be an integer and you pass a string as xml element value a string, the UncaughtExceptionHandlers will not be called and a generic 500 exception will be retunerd in text/html with a generic description “Input string was not in a correct format.” Stack Trace says:

[SerializationException: DeserializeDataContract: Error converting type: DeserializeDataContract: Error converting type: There was an error deserializing the object of type Geographic.Http.Services.CastError. Content cannot be converted to the type Int. Line 1, position 151.]
   ServiceStack.Serialization.DataContractSerializer.DeserializeFromString(String xml, Type type) +167
   ServiceStack.Host.Handlers.SoapHandler.ExecuteMessage(Message message, RequestAttributes requestAttributes, IRequest httpReq, IResponse httpRes) +1037

The point is: why the UncaughtExceptionHandlers has not been called while same use case for json format will be?

#7

There you go

the starting host solution is SS_ASPNET_01

on the swagger page you can call
http://localhost:56440/hello2/abc
and you break into UncaughtExceptionHandler …
but if you pass
http://localhost:56440/hello2/-23 (there is a validator that requires the number be < -1 … )
you wont’ break in any error handler , and not even in the globalresponsefilter , only the onendrequest is hit …

what we are trying to achieve is

  1. hooks to log any kind of errors in the service (but the 404)
  2. put a customized mesage in the ResponseStatus.Message in all error cases

thank you
enrico sabbadin

#8

@sabbadin12 thx for the repro we should now be raising ServiceExceptions for ValidationErrors in this commit.

@cris We should also be raising Service and Uncaught Exceptions for SOAP requests.

These changes is available from v4.0.41+ that’s now available on MyGet.

ValidatationFilters is ignoring custom errorResponse DTO
#9

thank you ,
two more things :
a) it seems that Onendrequest is not called for soap calls
b) it would be nice to have a appHost.EndRequest.Add(…); instead of having to override Onendrequest

thanks best regards
enrico

#10

@sabbadin12 OnEndRequest should now be called for SOAP calls.

You can also now use AppHost.OnEndRequestCallbacks to register callbacks.

These changes are now available on MyGet.

#11

Now UncaughtExceptionHandlers will be called for soap call as well, but only if the issue occurs on the input side (as per sample case pointed out here above).

In case the issue occurs on the output side, UncaughtExceptionHandlers will not be called and a generic html output will be returned including the stack trace

[SerializationException: Member RequiredProperty in type ResponseCustomizerSoapOutputDeserializationExceptionResponse cannot be serialized. This exception is usually caused by trying to use a null value where a null value is not allowed. The 'RequiredProperty' member is set to its default value (usually null or zero). The member's EmitDefault setting is 'false', indicating that the member should not be serialized. However, the member's IsRequired setting is 'true', indicating that it must be serialized. This conflict cannot be resolved. Consider setting 'RequiredProperty' to a non-default value. Alternatively, you can change the EmitDefaultValue property on the DataMemberAttribute attribute to true, or changing the IsRequired property to false.]

//ServiceModel
[DataContract(Namespace = Constants.SVC_NS)]
public class ResponseCustomizerSoapOutputDeserializationException
{
}

[DataContract(Namespace = Constants.SVC_NS)]
public class ResponseCustomizerSoapOutputDeserializationExceptionResponse
{
	[DataMember(EmitDefaultValue = false, IsRequired = true)]
	public string RequiredProperty { get; set; }
}

//ServiceInterface
public object Any(ResponseCustomizerSoapOutputDeserializationException request)
{
	return new ResponseCustomizerSoapOutputDeserializationExceptionResponse();
}
#12

Response SOAP Serialization exceptions should now fire IAppHost.ServiceExceptionHandlers from this commit.

This change is available from v4.0.41+ that’s now available on MyGet.

#13

Hi Demmis,
Thanks for your quik reply/fix, but IMHO now is even worst:
The hook will be now called after OnEndRequest, so I’m not able to customize the response and now, if I do not handle it, my serialization error on the output side disappear, if I do handle it,I’m not able to distinguish between normal service exception and serialization exception.

Why you decide to handle it as UncaughtExceptionHandlers instead of UncaughtExceptionHandlers?
IMHO should be handled as an UncaughtExceptionHandlers: serialization issue should be always treat in the same way no matter if the error occurs during the input o during the output.

Said so, please make the output serialization exception handled as UncaughtExceptionHandlers and fire it before OnEndRequest or rollback to previous implementation.

#14

Since we know the Service that’s executed it fires the IAppHost.ServiceExceptionHandlers but it’s now been modified it so OnEndRequest() is called after the handlers. This change is available on MyGet.

If you prefer you can modify it to call UncaughtExceptionHandlers by overriding IAppHost.WriteSoapMessage, e.g:

public override void WriteSoapMessage(IRequest req, System.ServiceModel.Channels.Message message, Stream outputStream)
{
    try
    {
        using (var writer = XmlWriter.Create(outputStream, Config.XmlWriterSettings))
        {
            message.WriteMessage(writer);
        }
    }
    catch (Exception ex)
    {
        OnUncaughtException(req, req.Response, req.OperationName, ex);
    }
    finally
    {
        HostContext.CompleteRequest(req);
    }
}
#15

Hi,
now ServiceExceptionHandlers has been called before OnEndRequest, but still I’m not able to distinguish between exception occured within the service method or outside such as serialization during the output.
An other issue with this new changes is the retuned object from the ServiceExceptionHandler will not be written in the output, but the previous one will be (the one created before the serialization error raised)

the override you proposed has 2 issue: a minor one

HostContext.CompleteRequest(req);

is internal. So I tried to call it via reflection

the major one is the output contains “2 outputs”: the original one before the serialization error occurs + the custom one I create through the custom uncaughtException handler. In short the response buffer has not been clean it out.My uncaughtExceptionHandler implementation down below (based on \src\ServiceStack\HttpResponseExtensionsInternal.cs)

private void uncaughtExceptionHandler(IRequest req, IResponse res, string operationName, Exception ex)
{
    //my output customization
	var errorDto = createResponseStatusForUncaughtException(operationName, ex);

	var httpReq = req;
	var httpRes = res;
	var contentType = httpReq.ResponseContentType;
	var statusCode = (int) HttpStatusCode.InternalServerError;


	if (httpRes.ContentType == null || httpRes.ContentType == MimeTypes.Html)
	{
		httpRes.ContentType = contentType;
	}
	if (HostContext.Config.AppendUtf8CharsetOnContentTypes.Contains(contentType))
	{
		httpRes.ContentType += ContentFormat.Utf8Suffix;
	}

	//TODO VERIFY IF StatusDescription EVER USED in the response to the client
	if (httpRes.StatusDescription == null || httpRes.StatusDescription == "OK")
	{
		string statusDescription = (((dynamic) errorDto).Message).ToString();
		// if string is longer than 512 .net raises an exception
		httpRes.StatusDescription = statusDescription.Truncate(509) + "...";
	}

	httpRes.StatusCode = statusCode;

	ResponseSerializerDelegate serializer = null;

	if (contentType == "application/soap+xml")
	{
		// custom serializer to avoid an exception due to missing SoapMessage within the request in case of not-serializable input
		serializer = SerializeSoap12ToStream;
	}
	else
	{
		serializer = HostContext.ContentTypes.GetResponseSerializer(contentType);

	}

	if (serializer != null)
	{
		serializer(httpReq, errorDto, httpRes);
	}

	httpRes.EndHttpHandlerRequest(skipHeaders: true);
}
#16

Instead of HostContext.CompleteRequest() you can call OnEndRequest() directly.

The ResponseBuffer could be dirty at this point so I’ve avoided writing the response but have changed it in this commit to write it if the ResponseStream is reset-able, i.e. if it’s using a BufferedStream. The test also shows it uses a buffered output stream for SoapDeserializationException requests, e.g:

if (dto is SoapDeserializationException)
    req.Response.UseBufferedStream = true;

You can determine when the exception was thrown by setting a flag in IRequest.Items, e.g:

try {
    return response;
} finally {
    base.Request.Items["serviceCompleted"] = true;
}

I’ll have this deployed to MyGet after a few hours.

#17

Change is now on MyGet.

#18

Tomorrow at work I’ll try the new build.
Not sure I understood the strategy to make an assumption on a specific dto: serialization issue may occur on any dto.

The goal is to return a custom dto in case that serialization error occured, not necessary the one related to the request, same as per uncaught exception handler since the proper response dto is not serializable at that time/during that specific request.

#19

Should I do it explictly on each service method, or are you going to add it? If I have to do it, which is the best way to do it as AOP(aspect)?

#20

There’s no strategy or assumption, it’s making it implicit which test requires a buffered response so any non-default configuration is limited to just the tests that need it.

You can look at req.Response.Dto != null which will be populated with the Service’s response to determine if the Service executed successfully.