Codecov Report

Merging #176 into master will decrease coverage by 0.37%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   80.89%   80.51%   -0.38%     
==========================================
  Files          29       29              
  Lines        2392     2397       +5     
  Branches      402      403       +1     
==========================================
- Hits         1935     1930       -5     
- Misses        302      312      +10     
  Partials      155      155

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1e0ba0...5be012e. Read the comment docs.

@jrideout thanks! I believe we want to somehow expose this on the scope instead of having special options on the logger though. That approach did not scale well in Raven.

@untitaker Can you please describe what you mean by scope in this context?

For some context, we've configured our lambda based apps to use:

sentry_logging = LoggingIntegration(level=logging.INFO, event_level=logging.WARNING)
sentry_sdk.init(
    integrations=[sentry_logging, AwsLambdaIntegration()],
    attach_stacktrace=True,
    environment=os.environ.get('SENTRY_ENVIRONMENT', 'dev'),
)

Which is probably sending way too much. I was hoping to turn off attach_stacktrace and use the extra based mechanism for getting stacks when logging.

@jrideout we have these scopes to override default values:

with push_scope() as scope:
    scope.fingerprint = ['foobar']

    capture_exception()  # custom fingerprint

capture_exception()  # no custom fingerprint

I wonder whether we can use scopes here too:

with push_scope() as scope:
    scope.attach_stacktrace = True

    logger.error(...)

I realize this is not optimal but I want to get rid of the weird arguments on logging calls

What about using exc_info=True for the non-exception use case as well? That would give a consistent user experience.

I like that idea, not sure if we have this info. @mitsuhiko what do you think?

@untitaker looks like we do have the full record in the handler. The logging system converts exc_info to a 3-value tuple of (type, value, traceback). In the case where we aren't in a exception, this tuple is (None, None, None).

Ah yes, the (None, None, None) tuple. That should work.

@jrideout thanks for your work. Please allow me some time to think it through. I think we're good though

Let's keep this open, I will check it out tomorrow

oops, I don't know how I closed this, I didn't mean too!

Thanks!