Closed barnabaskecskes closed 8 years ago
Pretty weird. Do you get any message along with error 35? Or doesn't it tell you any more than that? This is an underlying error with cURL rather than this package or Guzzle.
For what it's worth, error 35 is related to SSL:
CURLE_SSL_CONNECT_ERROR (35)
A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths, permissions), passwords, and others.
This I have experienced on a live production server. I will try to recreate the issue locally and will get more info for you. Thanks for looking into it.
@barnabaskecskes I'm going to close this for now. If you have any fresh information, post back and we can take another look.
The error thrown is:
[Guzzle\Http\Exception\CurlException] [curl] 35: [url] https://someservice.com/api
This only comes if the notification is being sent from a child-process of the parent process which initially used the library. In my case, I'm running a web socket server, which starts child processes for other nodes like a load balancer or the workers for example. The Slack notification was used in the main process twice - when booting and once booted. In between those two notifications I start the child processes (so it's not the first instance causing problems but rather the child process). Whenever a child process tries to send a notification, the above error is thrown. It is not only Slack - my email provider call did throw the exact same error after calling Slack in the main process.
The project I had the trouble is built in Laravel 5.0 and I used the facade to send the notifications in each place
\Slack::send('message');
. Removing the Slack notifications (and the package completely) did sort the problem and I can reach out to my email provider again.