sethtrain / raven-clj Goto Github PK

Sentry supports a user key on the event payload:

• https://develop.sentry.dev/sdk/event-payloads/user/
• https://develop.sentry.dev/sdk/event-payloads/types/#user

raven-clj.ring/wrap-sentry supports a http-alter-fn to amend the sentry.interfaces.Http event payload. There is currently no way to amend the event as a whole, i.e. there is no way to insert a user key into the event (outside the request / HTTP payload).

In Raven 1.7.0 capture is:

Raven always overrides event_id. Thus retrying capture (e.g. in case of network errors) would create additional events, making capture not idempotent.

It would we nice if the event_id could be passed in by the caller, so the caller could safely retry capture in case of e.g. network errors.

Usage of clj-http is limited to this one call. Probably there are lighter libraries to achieve the same, clj-http-lite comes to mind.

    (http/post url
               {:insecure? true
                :throw-exceptions false
                :headers {"X-Sentry-Auth" header
                          "User-Agent" sentry-client}
                :body (json/generate-string packet-info)})))

https://github.com/sethtrain/raven-clj/blob/master/src/raven_clj/core.clj#L27-L32

via #8

Yeller provides a default uncaught exception handler which can be used to catch stuff that doesn't get caught by application code: https://github.com/yeller/yeller_java/blob/master/src/com/yellerapp/client/YellerHTTPClient.java#L10

There's no guarantee that (nth source 5) will not blow up.

On a Windows machine, utf-8 strings passed to raven/capture will not be properly encoded when sent to Sentry.

As far as I can tell, this is because something in the http stack is using the default file encoding.
Temporary workaround:
Launch the JVM with -Dfile.encoding=utf-8

Potential solution:
Explicitly encode the body into utf-8 bytes.

(defn send-packet [{:keys [ts uri project-id key secret] :as packet-info}]
  (let [url (make-sentry-url uri project-id)
        header (make-sentry-header ts key secret)
        body (dissoc packet-info :ts :uri :project-id :key :secret)]
    (http/post url
               {:throw-exceptions false
                :headers {"X-Sentry-Auth" header
                          "User-Agent" sentry-client}
                :body (util/utf8-bytes (json/generate-string body))}))) ; <------

It's useful to have the full stack of exceptions when sending to sentry, otherwise if you wrap an exception with additional information it is dropped before sending it to sentry.

Was wondering if you could help me identify what's wrong here:

Notice session is showing [object Object]. I've forked the repo and tried printing a string representation of session, and it returns {}.

I'm using wrap-sentry with no options other than the DSN. Any ideas?

Under Clojure 1.7-alpha5 (final 1.7 release is soon) raven-clj causes the following warning:

WARNING: update already refers to: #'clojure.core/update in namespace: clj-http.client, being replaced by: #'clj-http.client/update

It's because of the dependency on clj-http 0.6.4 (very old). This has been fixed in clj-http for some time now.

Thanks!

It looks like the library has no way to set custom network timeouts on capture and by default no timeouts are set by the underlying HTTP lib. In theory, it can lead to long (or even infinite?) pauses in case the sending is performed synchronously.

Viewing issues for my Clojure projects on Sentry, the "Body" section always shows {}. It seems like its not capturing the request params at all for some reason? The other sections - "Cookies", "Headers" - are filling correctly (although I do have the issue in #15 for sessions).

I'm using raven-clj 1.4.3. In sentry's Detail View under "SDK" the version is reported as 1.4.2.
I guess raven-clj.core/sentry-client probably has to be updated (along with some tests, and maybe project.clj)

Our team has added a feature to include the ex-data in the GetSentry report as an extra parameter in the ring wrapper. I was wondering if this is a feature that would be valuable in the core project. If it is, happy to spin up a PR with the changes. It would look something like this commit without our team's specific configuration. Happy to discuss and adjust the PR as needed. Thanks!