Google.Ads.Common 8.1 can't work correctly with v201705

[ducaihua]

Hi,

I am trying to upgrade my AdWords library version to 22.3.0 (and Ads.Common to 8.1), and my application is still using v201705. It looks like this combination is not working well if there is any exception throw when calling the AdWords services.

Basically, in my error handling logic, I will try/catch any exceptions thrown from AdWords and cast it into Google.Api.Ads.Common.Lib.AdsException, and then I will try to get more details from those exception.

After I upgraded to the latest AdWords version, and talk to v201705 services, the exception I got back is System.ServiceModel.SystemFaultException which blocks me from casting to any AdsException. This issue does NOT exist if I talk to v201710 services.

It seems to me a back compatibility bug in the SDK (when talking to v201705). Could you please help fix this?

Thanks,
Caihua.

[AnashOommen]

Could you pls attach a SOAP log in both cases after redacting your developer token and auth headers?

[ducaihua]

Can you please let me know how to capture SOAP log after upgrading to v22.3? According to the migration guide, there is no way to log the SOAP logs anymore:
https://github.com/googleads/googleads-dotnet-lib/wiki/Upgrading-your-client-library-to-v22.0.0
I tried fiddler and didn't get any good luck though..

[ducaihua]

Also attached a call stack of the exception for your reference (if that helps):

System.ServiceModel.FaultException`1[Google.Api.Ads.AdWords.v201705.ApiException]: [AuthenticationError.CUSTOMER_NOT_FOUND @ ; trigger:'']

Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Google.Api.Ads.AdWords.v201705.CustomerServiceInterface.getCustomers(getCustomersRequest request)
at Google.Api.Ads.AdWords.v201705.CustomerService.getCustomers()

[ducaihua]

Bad Response v201705.txt
Good Response v201710.txt

Ok, I got the response from Fiddler and attached.

Basically when talking to v201705, the response doesn't have "Content-Encoding: gzip" and this response can NOT be converted to a valid AdsException; however when talking to v201710, the response has a "Content-Encoding: gzip".

Hope this can help to do the troubleshooting.

Thanks!
Caihua.

[ducaihua]

@AnashOommen , hi Anash, can you please let me know if this can be fixed shortly? We are depending on this fix to ship our new feature, thank you very much!

[AnashOommen]

Could you try repeating the exercise with gzip compression turned off? I suspect that this is related to #116. I'll definitely take a look tomorrow and try to get an update for you.

[ducaihua]

Thank you Anash! Could you please be more specific on how to turn off the gzip for those SOAP calls? I can definitely have a try by using the same steps? @AnashOommen

[ducaihua]

I assume you meant to set "EnableGzipCompression" to false at the request header?

[AnashOommen]

yep, see if that take care of things. That disables compression of gzip, and hopefully it should work. WCF implementation of handling gzip compression is unfortunately not very consistent across various situations, and platforms. Bandwidth usage would be higher, but if it works as a temporary fix then that's good.

[ducaihua]

Hi Anash, I tried to put the headers there and tried both true/false value when talking to v201705, however neither of them seem work..

My suspicion is that when talking to "v201705" (which is not WCF implemented service ?), the 8.1 library can't decode the exception response successfully.

I will leave it to you to take a look when you get a chance .

Thank you very much and appreciate your help here! @AnashOommen

[ducaihua]

Hello Anash, gentle ping in case you have any update/workaround for us to try. Thank you! @AnashOommen

[AnashOommen]

Have a fix. Will plan a push today.

[AnashOommen]

I'll get the release done tomorrow. For now, if you can compile from the csproj, you have to change the src\Common\Lib\SoapFaultInspector.cs to replace the AfterReceiveReply method like this:

public void AfterReceiveReply(ref Message reply, object correlationState) {
      if (reply.IsFault) {
        using (MessageBuffer buffer = reply.CreateBufferedCopy(Int32.MaxValue)) {
          // Message can only be read once, so replace it with a copy.
          reply = buffer.CreateMessage();
          Message copy = buffer.CreateMessage();

          // Get the body contents.
          XmlReader reader = copy.GetReaderAtBodyContents();

          // Try locating the ApiExceptionFault node and deserializing it. Make sure to ignore
          // the namespace and look only for the local name.
          XmlDocument xDoc = new XmlDocument();
          xDoc.LoadXml(reader.ReadOuterXml());
          XmlElement faultNode = (XmlElement) xDoc.SelectSingleNode(FAULT_ELEMENT_XPATH);

          if (faultNode != null) {
            // Deserialize the correct exception type and raise it.
            string faultNodeNamespaceUri = faultNode.NamespaceURI;
            string faultNodeContents = faultNode.OuterXml;
            object apiError = SerializationUtilities.DeserializeFromXmlTextCustomRootNs(
                faultNodeContents,
                ErrorType,
                faultNodeNamespaceUri,
                FAULT_ELEMENT_NAME);
            throw (TException) Activator.CreateInstance(
                typeof(TException),
                new object[] { apiError });
          }
        }
      }
    }

[ducaihua]

Thank you @AnashOommen! We don;t compile the adwords sdk source code in our project, I will wait for your new release ready. Thank you again for your quick turnaround!

Caihua.

[AnashOommen]

FYI we pushed a new version of Common and AdWords libraries. Pls try it out and let me know if the issue is fixed.

[ducaihua]

Hi Anash, I have verified and it works, thank you so much dofor your prompt response! Thanks, Caihua

…

On Tue, 7 Nov 2017 at 10:41 AM Anash P. Oommen ***@***.***> wrote: FYI we pushed a new version of Common and AdWords libraries. Pls try it out and let me know if the issue is fixed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#124 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEqCVKSZfwHnaZTcwxzEsHPQ-oFqjdR6ks5s0KQ6gaJpZM4QQfRt> .