Sudden "SoapFault: Could not connect to host"

[lezhnev74]

We see the same error on production and local/development when sending some requests to bing ads api. We started to see it on older version, after upgrading to the recent one errors remain.

In logs I see that only certain requests return that error, while others return successful results. Among problematic requests are: GetUser and SearchAccounts. Setting retry timeouts does not help, the error is reproducible 100% of times.

Any hints what to do here?

[lezhnev74]

I think I got it, there is somethign weird returned in https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc\?singleWsdl

run

curl https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc\?singleWsdl | grep 'location=".*"'

which shows weird location:

<soap:address location="https://[::]/Api/CustomerManagement/v13/CustomerManagementService.svc" />

compared to the same location in

curl https://campaign.api.sandbox.bingads.microsoft.com/Api/Advertiser/CampaignManagement/v13/CampaignManagementService.svc\?singleWsdl | grep 'location=".*"'

<soap:address location="https://campaign.api.sandbox.bingads.microsoft.com/Api/Advertiser/CampaignManagement/v13/CampaignManagementService.svc"/>

p.s. That explains why only customer related requests failed.

[weilinzung]

same

[AAATechGuy]

acknowledging, working on mitigation. ETA 2022-09-26 14:00 PST.

[AAATechGuy]

Need more clarifications here to follow-up.

1. Assume https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc\?singleWsdl - it's CustomerManagementService.svc?singleWsdl instead of CustomerManagementService.svc\?singleWsdl

2. how does the return address in wsdl response affect you in wsdl generation process? <soap:address location="https://[::]/Api/CustomerManagement/v13/CustomerManagementService.svc" />

3. Does it affect your current runtime calls against BingAds? Curious, if it breaks your runtime,

   • is it because you are starting new code?
   • or, did it break an existing scenario? if so, may I know, why do you need to generate wsdl often? Isn't wsdl generation supposed to be static (because metadata rarely changes)

[AAATechGuy]

Issue mitigated in Production as of 2022-09-26 11:45 PST. Let know if issue still exists.

[rosslavery]

Still seeing the issue as of 2022-09-26 16:19 EST.

Source: $bingAdsClient->GetService()->GetUser($userRequest)->User;

[AAATechGuy]

@rosslavery @weilinzung @lezhnev74 can you please help answer these...

Need more clarifications here to follow-up.

1. Assume https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc\?singleWsdl - it's CustomerManagementService.svc?singleWsdl instead of CustomerManagementService.svc\?singleWsdl
2. how does the return address in wsdl response affect you in wsdl generation process? <soap:address location="https://[::]/Api/CustomerManagement/v13/CustomerManagementService.svc" />

3. Does it affect your current runtime calls against BingAds? Curious, if it breaks your runtime,

   • is it because you are starting new code?
   • or, did it break an existing scenario? if so, may I know, why do you need to generate wsdl often? Isn't wsdl generation supposed to be static (because metadata rarely changes)

[rosslavery]

1. Sorry I don't know what you mean by this
2. Sorry I don't know
3. Yes, it affects our current runtime calls. Not new code, an existing codebase that has been untouched for months. As far as I know we aren't generating wsdl often, we're just using the Bing Ads PHP Client Library (this repo) in the recommended way from the documentation.

[AAATechGuy]

Issue mitigated in SI/Sandbox as of 2022-09-26 16:45 PST. Let know if issue still exists.

Sandbox URL: https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc?singleWsdl

Production URL: https://clientcenter.api.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc?singleWsdl

Issue mitigated in Production as of 2022-09-26 11:45 PST. Let know if issue still exists.

[AAATechGuy]

@rosslavery @weilinzung @lezhnev74
After the mitigation earlier in the day, tonight we had updated sandbox environment (i.e., service serving from https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc?singleWsdl) to deploy our previous changes after fixing RC of the issue described above (invalid soap:address location). Please let know here, if you face any further problems in Sandbox environment. We plan to take the change forward tomorrow to Production.

[lezhnev74]

Yeap, confirmed, our local env works as usual! Thanks a lot! I see that location has been fixed on both sandboxed and production endpoints.

[rosslavery]

We're still seeing the issue on production...

Could not connect to host... Stacktrace pointing to $bingAdsClient->GetService()->GetUser($userRequest)->User;.

Started yesterday at the exact same time this issue was posted so I have to believe they are related...

Edit: restarting our VM instance seemed to have resolved it (wsdl cached?), waiting for another confirmation...

[lezhnev74]

Most likely that was cache, because this command shows correct location:

curl https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc\?singleWsdl | grep 'location=".*"'

[AAATechGuy]

@rosslavery @weilinzung @lezhnev74 we are promoting the previous change (with fixes to location), from sandbox to production, at 1% traffic now. Will increase gradually to 50% tomorrow, and plan to GA next Tue in Production. Please let us know if you face any issues. Thanks!

@rosslavery @weilinzung @lezhnev74 After the mitigation earlier in the day, tonight we had updated sandbox environment (i.e., service serving from https://clientcenter.api.sandbox.bingads.microsoft.com/Api/CustomerManagement/v13/CustomerManagementService.svc?singleWsdl) to deploy our previous changes after fixing RC of the issue described above (invalid soap:address location). Please let know here, if you face any further problems in Sandbox environment. We plan to take the change forward tomorrow to Production.

[rosslavery]

After having worked for the past ~1 day (after the revert of the previous change) -- we are encountering issues again when creating customers.

Tried restarting our instance in case of a wsdl caching issue.

The following line in our code usually logs the SOAP response containing details about the problem.

Log::error(print $bingAdsClient->GetService()->__getLastResponse()."\n");

Now, that line simply logs: 1, containing no details of the actual error.

[AAATechGuy]

@rosslavery where are you seeing this issue, in sandbox or production.

@lezhnev74 @weilinzung are you facing similar issues.

[rosslavery]

In production. When creating a customer. I can provide the SOAP request logs / tracking ID privately, but the response is not helpful like I mentioned 😔

[AAATechGuy]

plz paste the Timestamp and TrackingId from server, if possible. Thanks.

[qitia]

@rosslavery , could you please also share the request by removing the sensitive info, if possible?

[rosslavery]

Request SOAP (details removed). Timestamp: 2022-09-29 14:01:32 GMT TrackingId: d989d18f-a003-427f-9fb8-d8c1c50e912b

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="https://bingads.microsoft.com/Customer/v13/Entities" xmlns:ns2="https://bingads.microsoft.com/Customer/v13" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <SOAP-ENV:Header>
      <ns2:CustomerAccountId />
      <ns2:CustomerId />
      <ns2:DeveloperToken>XXXXXXXXXX343793</ns2:DeveloperToken>
      <ns2:UserName />
      <ns2:Password />
      <ns2:AuthenticationToken>xxxx</ns2:AuthenticationToken>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      <ns2:SignupCustomerRequest>
         <ns2:Customer>
            <ns1:CustomerFinancialStatus xsi:nil="true" />
            <ns1:Id xsi:nil="true" />
            <ns1:Industry>Other</ns1:Industry>
            <ns1:LastModifiedByUserId xsi:nil="true" />
            <ns1:LastModifiedTime xsi:nil="true" />
            <ns1:MarketCountry>US</ns1:MarketCountry>
            <ns1:ForwardCompatibilityMap xsi:nil="true" />
            <ns1:MarketLanguage>English</ns1:MarketLanguage>
            <ns1:Name>XXXX</ns1:Name>
            <ns1:ServiceLevel xsi:nil="true" />
            <ns1:CustomerLifeCycleStatus xsi:nil="true" />
            <ns1:TimeStamp xsi:nil="true" />
            <ns1:Number xsi:nil="true" />
            <ns1:CustomerAddress>
               <ns1:City>Los Angeles</ns1:City>
               <ns1:CountryCode>US</ns1:CountryCode>
               <ns1:Id xsi:nil="true" />
               <ns1:Line1>XXXX</ns1:Line1>
               <ns1:Line2 xsi:nil="true" />
               <ns1:Line3 xsi:nil="true" />
               <ns1:Line4 xsi:nil="true" />
               <ns1:PostalCode>XXXX</ns1:PostalCode>
               <ns1:StateOrProvince>CA</ns1:StateOrProvince>
               <ns1:TimeStamp xsi:nil="true" />
               <ns1:BusinessName>XXXX</ns1:BusinessName>
            </ns1:CustomerAddress>
         </ns2:Customer>
         <ns2:Account>
            <ns1:BillToCustomerId xsi:nil="true" />
            <ns1:CurrencyCode>USD</ns1:CurrencyCode>
            <ns1:AccountFinancialStatus xsi:nil="true" />
            <ns1:Id xsi:nil="true" />
            <ns1:Language>English</ns1:Language>
            <ns1:LastModifiedByUserId xsi:nil="true" />
            <ns1:LastModifiedTime xsi:nil="true" />
            <ns1:Name>XXXX</ns1:Name>
            <ns1:Number xsi:nil="true" />
            <ns1:ParentCustomerId>XXXX</ns1:ParentCustomerId>
            <ns1:PaymentMethodId xsi:nil="true" />
            <ns1:PaymentMethodType xsi:nil="true" />
            <ns1:PrimaryUserId xsi:nil="true" />
            <ns1:AccountLifeCycleStatus xsi:nil="true" />
            <ns1:TimeStamp xsi:nil="true" />
            <ns1:TimeZone>PacificTimeUSCanadaTijuana</ns1:TimeZone>
            <ns1:PauseReason xsi:nil="true" />
            <ns1:ForwardCompatibilityMap xsi:nil="true" />
            <ns1:LinkedAgencies>
               <ns1:CustomerInfo>
                  <ns1:Id>XXXX</ns1:Id>
                  <ns1:Name>XXXX</ns1:Name>
               </ns1:CustomerInfo>
            </ns1:LinkedAgencies>
            <ns1:SalesHouseCustomerId xsi:nil="true" />
            <ns1:TaxInformation xsi:nil="true" />
            <ns1:BackUpPaymentInstrumentId xsi:nil="true" />
            <ns1:BillingThresholdAmount xsi:nil="true" />
            <ns1:BusinessAddress>
               <ns1:City>Los Angeles</ns1:City>
               <ns1:CountryCode>US</ns1:CountryCode>
               <ns1:Id xsi:nil="true" />
               <ns1:Line1>XXXX</ns1:Line1>
               <ns1:Line2 xsi:nil="true" />
               <ns1:Line3 xsi:nil="true" />
               <ns1:Line4 xsi:nil="true" />
               <ns1:PostalCode>XXXX</ns1:PostalCode>
               <ns1:StateOrProvince>CA</ns1:StateOrProvince>
               <ns1:TimeStamp xsi:nil="true" />
               <ns1:BusinessName>XXXX</ns1:BusinessName>
            </ns1:BusinessAddress>
            <ns1:AutoTagType xsi:nil="true" />
            <ns1:SoldToPaymentInstrumentId xsi:nil="true" />
         </ns2:Account>
         <ns2:ParentCustomerId>XXXX</ns2:ParentCustomerId>
         <ns2:UserInvitation>
            <ns1:FirstName>XXXX</ns1:FirstName>
            <ns1:LastName>XXXX</ns1:LastName>
            <ns1:Email>XXXX</ns1:Email>
            <ns1:AccountIds xsi:nil="true" />
            <ns1:Lcid>EnglishCanada</ns1:Lcid>
         </ns2:UserInvitation>
      </ns2:SignupCustomerRequest>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

[AAATechGuy]

We have done preliminary investigation and feel this issue isn't related to the wsdl issue being discussed on this thread. After our recent wsdl changes, we had validated PHP BingAdsAPI scripts against it and believe issues described SoapFault: Could not connect to host should be resolved.

Please let us know if you see similar issues for wsdl seen above SoapFault: Could not connect to host, or feel free to create new thread with the new problem (so we track it better).