locked
DS Client not reporting exceptions correct in $batch POST requests. RRS feed

  • Question

  • Hi,

    In situations where an entire batch POST request fails (HTTP result = 500) the WCF DS Client does not report the full exception as recieved from the server. You just get a standard "The remote server returned an error: (500) internal server error."

    Fidler shows the correct error response (in my case with stack trace and everything) is actually sent from the server.

    It works as expected for non batch POST requests. It also work as expected when one or more individual POSTs in a batch fails (HTTP result = 202).

    This must be a bug in DS Client?

    Regards

    Uffe

    Tuesday, May 22, 2012 5:31 AM

Answers

  • Hi,

    Unfortunately this a kind of "by design". We shipped this bug in one of the previous versions and we can't really fix it, since changing exception types is considered a breaking change which we didn't want to take.

    There are two possible workarounds:

    1) When you catch the exception, cast it to WebException, access its Response property and read the response stream yourself. It is not that nice but it's not hard either. You could use ODataLib to read the response for you so that you don't have to parse it.

    2) Use the async variant of the batch request, since this bug only exists in the sync variant. So if you're using SaveChanges(Batch), replace it with var ar = BeginSaveChanges(Batch); EndSaveChanges(ar); (the End call will block until the operation finishes so you effectively turned the async operation into a synchronous one). The End call should throw DataServiceException which has the body of the response parsed in it in the usual way.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by Uffe Lauesen Wednesday, May 23, 2012 1:25 PM
    Wednesday, May 23, 2012 8:44 AM
    Moderator
  • Thanks Vitek,

    So the answer is...

    1. Yes it is a bug in DS Client

    2. It will NOT be fixed.

    Thank you

    Uffe

    • Marked as answer by Uffe Lauesen Wednesday, May 23, 2012 1:25 PM
    Wednesday, May 23, 2012 1:25 PM

All replies

  • Which client you are using , are you using " System.Data.Services.Client"

    If you are using any custom error handling then can you please share some code fragment 

    Tuesday, May 22, 2012 5:56 AM
  • Yes - System.Data.Services.Client version 5.0.

    In a Custom provider do the following...

    protected override void OnStartProcessingRequest(ProcessRequestArgs args)
    {
        if (args.OperationContext.RequestMethod == "POST")
        {
            if (args.RequestUri.AbsolutePath.Split('/').Where(p => !string.IsNullOrEmpty(p)).LastOrDefault() != "$batch")
                throw new NotSupportedException("Non batch part of request - provoked error");
            else
                throw new NotSupportedException("Batch part of request - provoked error");
        }
    }

    On a WCF DS Client make a POST (create) $batch request to your service (ctx.SaveChanges(SaveChangesOption.Batch)).

    Notice that you get a general 500 internal server errror on you client. The message "Batch part of request - provoked error" is not included in the inner error.

    Now remove that exception from the server code. Now notice that the "Non batch part of request - provoked error" is correctly present in the inner error part of the client exception.

    Clear?

    Regards

    Uffe

    Tuesday, May 22, 2012 8:33 AM
  • Can you try HandleException Override function

    Also make sure 

    • Is your class decorated with  [ServiceBehavior(IncludeExceptionDetailInFaults = true)]
    • and is  config.UseVerboseErrors = true; set in service in InitializeService(DataServiceConfiguration config)

    Please let us know it it helps 

    Regards

    Ashwini

    Tuesday, May 22, 2012 10:35 AM
  • No you are missing the point!

    Fiddler shows correctly a DS exception is transefered to the client.

    It is on the CLIENT the exception is not properly transformed into a DS client exception!

    Thanks for replying any ways.

    Regards

    Uffe

    Tuesday, May 22, 2012 6:13 PM
  • Ya Looks true , 

    I tried simulating your condition in a sample service and i am able to see expected error trace in all the browsers 

    Look like a client side issue , You can report to Microsoft Connect 

     protected override void OnStartProcessingRequest(ProcessRequestArgs args)
            {
                throw new NotSupportedException("Test Exception");
    
            }
      <?xml version="1.0" encoding="utf-8" standalone="yes" ?> 
    - <error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
      <code /> 
      <message xml:lang="en-US">An error occurred while processing this request.</message> 
    - <innererror>
      <message>Test Exception</message> 
      <type>System.NotSupportedException</type> 
      <stacktrace>at SampleDataService.WcfDataService1.OnStartProcessingRequest(ProcessRequestArgs args) in D:\Temp\WcfDataService1.svc.cs:line 34 at System.Data.Services.DataService`1.System.Data.Services.IDataService.InternalOnStartProcessingRequest(ProcessRequestArgs args) at System.Data.Services.DataService`1.ProcessIncomingRequestUri() at System.Data.Services.DataService`1.HandleRequest()</stacktrace> 
      </innererror>
      </error>
    Can you check the client side exception handling code may be you are missing right casting because I have face same issue in with HTTPWebExpetion in which InnerException was NULL but actual error information was stored in a WebResponce property that only got reveled when i did a conditional type costing of incoming exception that was of type Exception.

    Tuesday, May 22, 2012 6:45 PM
  • Thanks for testing and verifying.

    I don think it is a casting issue on the client, basically I am just looking at the clent exception.ToString() and this one is just a generic one with no OData error information.

    I would expect Vitek or some other MSFT person to drop by here and confirm and bugbase this.

    Regards

    Uffe

    Tuesday, May 22, 2012 7:46 PM
  • Hi,

    Unfortunately this a kind of "by design". We shipped this bug in one of the previous versions and we can't really fix it, since changing exception types is considered a breaking change which we didn't want to take.

    There are two possible workarounds:

    1) When you catch the exception, cast it to WebException, access its Response property and read the response stream yourself. It is not that nice but it's not hard either. You could use ODataLib to read the response for you so that you don't have to parse it.

    2) Use the async variant of the batch request, since this bug only exists in the sync variant. So if you're using SaveChanges(Batch), replace it with var ar = BeginSaveChanges(Batch); EndSaveChanges(ar); (the End call will block until the operation finishes so you effectively turned the async operation into a synchronous one). The End call should throw DataServiceException which has the body of the response parsed in it in the usual way.

    Thanks,


    Vitek Karas [MSFT]

    • Marked as answer by Uffe Lauesen Wednesday, May 23, 2012 1:25 PM
    Wednesday, May 23, 2012 8:44 AM
    Moderator
  • Thanks Vitek,

    So the answer is...

    1. Yes it is a bug in DS Client

    2. It will NOT be fixed.

    Thank you

    Uffe

    • Marked as answer by Uffe Lauesen Wednesday, May 23, 2012 1:25 PM
    Wednesday, May 23, 2012 1:25 PM