getsentry / perl-raven Goto Github PK

Right now the various ->$foo_context methods (eg. request_context) return only the appropriate context.

Eg. if you do

my %returned_context = Sentry::Raven->request_context(
    %relevant_request_information,
    tags => { foo => 'bar' }
);

then %returned_context will not contain any information about those tags (and there will be no warnings).

This can be surprisingly different than the capture_request call (which does observe non-request context), and besides can lead to slightly over-verbose code like:

    my ($url, %context) = get_sentry_context_from_request($req);
    $sentry->capture_message($message, %context, Sentry::Raven->request_context($url, %context));

(instead of

    my ($url, %context) = get_sentry_context_from_request($req);
    $sentry->capture_message($message, Sentry::Raven->request_context($url, %context));

)

Would you have any interest in a patch to make request_context and company behave more like their capture_ counterparts (and also allow chaining)?

The documentation for the logger parameter suggests that it defaults to the current user, but it actually defaults to root.

It'd be nice if Sentry::Raven could also gather partial source code around each line of the stacktrace. This is how it looks out of the box for Python events:

    my $sentry_dsn = $ENV{SENTRY_DSN} || $args{sentry_dsn}
        or die "must pass sentry_dsn or set SENTRY_DSN envirionment variable\n";

This should be $args{sentry_dsn} || $ENV{SENTRY_DSN}. Explicit configuration via Sentry::Raven->new needs to be respected.

I got this when trying cpanm Sentry::Raven:

t/11-generic-event.t ...... ok
t/12-specialized-event.t .. ok
t/13-service-call.t ....... ok
t/14-does-not-die.t ....... ok

    #   Failed test at t/15-error-handler.t line 58.
    #          got: '8'
    #     expected: '7'

    #   Failed test at t/15-error-handler.t line 60.
    #          got: 'Sentry::Raven::__ANON__'
    #     expected: 'main::c'

    #   Failed test at t/15-error-handler.t line 61.
    #          got: 'Sentry::Raven'
    #     expected: 'main'

    #   Failed test at t/15-error-handler.t line 62.
    #          got: '/home/wqmisc/.cpanm/work/1598799198.18017/Sentry-Raven-1.13/blib/lib/Sentry/Raven.pm'
    #     expected: 't/15-error-handler.t'

    #   Failed test at t/15-error-handler.t line 63.
    #          got: 'Raven.pm'
    #     expected: '15-error-handler.t'

    #   Failed test at t/15-error-handler.t line 64.
    #          got: '239'
    #     expected: '34'
    # Looks like you failed 6 tests of 6.

#   Failed test 'stacktrace'
#   at t/15-error-handler.t line 65.
# Looks like you failed 1 test of 5.

Perl version is 5.16.2

Hello,

We're having a problem where subsequent events of an exception aren't being reported to sentry.

Basically we created a test file, cause an error it reports to sentry normally. Then we rerun but there's only one recorded event of the exception.

We're using VERSION: 1.10 with Sentry 8.20.0.

test.pl

use Sentry::Raven;
use strict;
use warnings;

sub sentry {
    return Sentry::Raven->new(sentry_dsn => <our-dsn>);
}

1;

We saw this error before in a python backend once, is this a bug in the Sentry::Raven perl module?

https://docs.sentry.io/quickstart/#configure-the-dsn

Secret key is no longer included in the DSN.

Environment

Sentry SaaS (sentry.io)
Sentry::Raven 1.13 in Perl 5.26.1 on Ubuntu 18.04.

Steps to Reproduce

Define a SENTRY_DSN environment variable or pass a sentry_dsn attribute without secret key (as defined at The Parts of the DSN) to

Sentry::Raven->new();

Expected Result

The initialization should happen silently.

Actual Result

The initialization fails with the error

unable to parse public and secret keys from: <SENTRY_DSN>

This originates from

Even examples (e.g. at JavaScript configuration) show this type of usage. Since the other client libraries (like Python or JavaScript) can handle it, so should the Perl client. Checking for the colon in the userinfo shouldn't be enforced.

My current workaround: Adding : (ie. an empty secret key) before the @ in the DSN.

Wondering if there are plans to add support for Performance Monitoring Support https://docs.sentry.io/performance-monitoring/getting-started ?

Thanks for the great work, we love Sentry and looking forward to gaining more functionality.

Got a support ticket suggesting the stacktrace frame order might be backwards in the Perl SDK.

I put up some informal docs for the Perl client on our new docs.getsentry.com site:

https://docs.getsentry.com/hosted/clients/perl/

We'd love to move this into the repo to support some various behaviors. If that sounds good, there's a couple of approaches we'd prefer to take:

1. Add a few of us as collaborators here
2. Let us move the repo to the getsentry org space (we'll retain the current permissions)

It's unlikely we'll be able to help maintain the SDK itself (as none of us use Perl), but we can help out with some of the community/documentation things.