Slack target: Error during transmission: HTTP client call failed Follow

Comments

10 comments

  • Avatar
    Tran Ba Quy

    hi, I have same problem, whenever I try to test, it returns "Error during transmission: HTTP client call failed", what should I do now?

  • Avatar
    Nicole - Community Manager

    Hi Tran - 

    Uninstall, then reinstall the Slack app under Admin > Apps > Manage. If you find that updates are still not pushing to Slack, submit a ticket to support@zendesk.com for further investigation.

  • Avatar
    Mike Uy

    Are you serious with this solution?

    I have a dozen slack channel integrations setup. Will I have to recreate all of those if I do this?

  • Avatar
    Michel

    Hello Tran and Mike, 

     

    This is indeed a generic solution and, if we want to see what exactly happened we would need to look into specific errors of these failures. 

    Since this will require more account specific troubleshooting. I'll send you both a proactive ticket to get to specific errors you might see on your end. 

    This is why we are asking you to contact us at support@zendesk.com if you are facing some issues, we would need to know what the exact error is to be able to determine what is happening. 

    Talk to you soon. 

    Cheers

  • Avatar
    Rebecca

    Hi everyone - 

    Sorry for all the confusion this issue has caused! I have gone ahead and edited this article with more concrete information surrounding the error. Let us know if you have any questions!

  • Avatar
    Alex Gerulaitis (Edited )

    Our Slack integration just got disabled with the same generic message:

    "The target '<custom> Slack Integration' has been temporarily disabled due to too many failures. You can re-enable the target from Settings -> Extensions -> Targets to continue sending messages to the target, but please check the possible reason of these failures by testing the target first."

    Testing the integration produces "Error during transmission: HTTP client call failed".

    Immediate questions:

    1. What are the failures and related error messages?
    2. How long have they been going on, how frequently, ratio of failures vs. successes? Is there a log of error messages anywhere? If not why not?
    3. How was the "too many failures" part determined? How is the decision to disable an integration made? If the errors started awhile ago, why weren't we notified first, before disabling the integration?

    (No proactive notifications of failures? No error log? Just kill the app? Seriously?)

  • Avatar
    Alex Gerulaitis

    "Test Target" button does not work on any of our integrations, including that are working otherwise.

    Looks like it's a bug.

  • Avatar
    Guy Dee

    Hi Alex! I'm sorry to hear about the trouble.

    In response to each of your immediate questions above:

    1. These error messages can be found on the Target Failures tab of the API dashboard under Admin > Channels > API. This list shows the response code, target name, and timestamp of the failure. Click on any individual record to see details about it, including the complete content of the request sent to the target, and the complete content of the target's response.
    2. The Target Failures tab should give a good impression of how long an issue has been ongoing for a particular target and how frequent it is. As noted above, detailed records of the response are recorded for every failure.
    3. A target is automatically deactivated if it fails 21 consecutive times with no successes (documented at the bottom of our article on target notifications). There is no lifetime or historical maximum for failures; the limit is only for consecutive failures. When a target is automatically deactivated in this way an email notification is sent to the account owner.

    I hope this information is helpful!

  • Avatar
    Alex Gerulaitis (Edited )

    Thanks Guy!

    • Accessing that log (Admin > Channels > API) required accepting API ToC even if all we wanted was the logs. Not sure if this is intended behavior - doesn't seem logical to me: if creating an integration doesn't require accepting new terms, accessing related logs shouldn't either.
    • Re: "target disabled" incident last week in our Zendesk instance, there are no log entires at all for that day. There is only one failure in the logs for the entire first half of 2018. I.e. we have no logs for that failure.
    • "Target disabled" emails sent to the owner of an instance should be sent to all admins - else the integration can suffer a much longer downtime due to lack of critical notifications. The owner (e.g. the principal of the business units or the purchasing agent) may not relay the critical notification until well into the downtime.
    • "Target disabled" emails should absolutely link to the logs - or at least mention their existence, and relevant KB articles - else an admin is spending time hunting down relevant KB articles vs. attempting to resolve the issue.
    • As mentioned in my previous comment, "test target" button always produces an error for us, including for targets that are working.
    • APIs / integrations should have a mechanism to proactively notify instance admins of failures, errors and warnings. Sending an email to the account owner only after the target is disabled is no way to treat an issue. (Would you prefer the "check engine" light to turn on once an issue is detected - or only after the engine dies?)

    Thank you again for the help.

  • Avatar
    Guy Dee

    Hi Alex -

    It sounds like this might be better handled in a support ticket where we can gather details about any issues you're experiencing. I'll reach out in a ticket shortly!

Please sign in to leave a comment.

Powered by Zendesk