I have a Slim 3.8 project that works with Sentry 2.0. But when I run scripts from the command line, nothing ends up in Sentry.
I’ve printed promise and response objects all the way into the HttpTransport class and see that messages are being built and sent. But nothing appears in Sentry. And I cannot tell what the status of the send is. Last thing I see is the promise is status “pending”.
Is there some magic to get PHP scripts from the command line to work with Sentry? Is there an easy way to debug lower-level stuff like this, like some way to turn on extra debug info within sentry?
I’m using SDK 2.2.2. Did it get fixed in 2.2.3? If there’s any online references to this (bugfix, pull-request, other forum posts, etc), I’d love to see them in case they have hints on what is happening.
Figured it out! I had a config issue, but will describe what happened in case it helps others. I apologize for wasting anyone’s time answering this.
I’m on a Windows system, running WAMP. I have a batch script that I run from the command-line to put the PHP executable on the system path, so it can be quickly run by typing “php”.
WAMP has two php.ini files in each of it’s PHP version folders. One called php.ini, and one called phpForApache.ini. The change I made to the Apache version (to make Sentry work when in a webpage), was not applied to the normal php.ini files, which the command line uses.
The change needed was to give curl a valid cert file, in the curl.cainfo setting. I use the one bundled with Firefox.
What would be nice
I’m not sure why Sentry v2 on Windows requires a CA cert this when v1 didn’t. But I’ve seen this issue in a few threads. It would be great if Sentry could check for this and warn the user, or document it better. Or at the least throw a meaningful error when the curl promise fails too many times. This issue was definitely my fault, but some sort of notification would have gone a long way to helping diagnose it.
Thank you for your explanation!
Just to reverify, you call to Sentry\captureMessage returned null correct?
Nevertheless, I agree, maybe if you turn on “debug mode” (which is yet to be implemented) of the SDK we could throw the error so you see what’s happening.