sentry-sidekiq-v4.1.1

Tag for release: 4.1.1

sentry-ruby-v4.1.1

• Fix NoMethodError when sending is not allowed #1161
• Add notification for users who still use deprecated middlewares #1160
• Improve top-level api safety #1162

sentry-rails-v4.1.1

Tag for release: 4.1.1

sentry-sidekiq-v4.1.0

Tag for release: 4.1.0

sentry-ruby-v4.1.0

• Separate rack integration #1138
  • Fixes #1136
• Fix event sampling #1144
• Merge & rename 2 Rack middlewares #1147
  • Fixes #1153
  • Removed Sentry::Rack::Tracing middleware and renamed Sentry::Rack::CaptureException to Sentry::Rack::CaptureExceptions.
• Deep-copy spans #1148
• Move span recorder related code from Span to Transaction #1149
• Check SDK initialization before running integrations #1151
  • Fixes #1145
• Refactor transport #1154
• Implement non-blocking event sending #1155
  • Added background_worker_threads configuration option.

Noticeable Changes

Middleware Changes

Sentry::Rack::Tracing is now removed. And Sentry::Rack::CaptureException has been renamed to Sentry::Rack::CaptureExceptions.

Events Are Sent Asynchronously

sentry-ruby now sends events asynchronously by default. The functionality works like this:

1. When the SDK is initialized, a Sentry::BackgroundWorker will be initialized too.
2. When an event is passed to Client#capture_event, instead of sending it directly with Client#send_event, we'll let the worker do it.
3. The worker will have a number of threads. And the one of the idle threads will pick the job and call Client#send_event.
   • If all the threads are busy, new jobs will be put into a queue, which has a limit of 30.
   • If the queue size is exceeded, new events will be dropped.

However, if you still prefer to use your own async approach, that's totally fine. If you have config.async set, the worker won't initialize a thread pool and won't be used either.

This functionality also introduces a new background_worker_threads config option. It allows you to decide how many threads should the worker hold. By default, the value will be the number of the processors your machine has. For example, if your machine has 4 processors, the value would be 4.

Of course, you can always override the value to fit your use cases, like

config.background_worker_threads = 5 # the worker will have 5 threads for sending events

You can also disable this new non-blocking behaviour by giving a 0 value:

config.background_worker_threads = 0 # all events will be sent synchronously

sentry-rails-v4.1.0

Tag for release: 4.1.0

sentry-ruby-v4.0.1

• Add rake integration: 1137
• Make Event's interfaces accessible: 1135
• ActiveSupportLogger should only record events that has a started time: 1132

sentry-sidekiq-v4.0.0

This is the first official release of Sentry's new Ruby SDKs.
Check our documentation to get started.
Take a look at the migration guide when upgrading from an older version.

If you are using the old sentry-raven client, here are the benefits of migrating to the new client:

• Unified Interfaces With Other SDKs: The design of sentry-raven is outdated compared with our modern Sentry SDKs. If you also use other Sentry SDKs, such as Sentry's JavaScript SDK for your frontend application, you'll notice that their interfaces are quite different from the one provided for sentry-raven. The new sentry-ruby SDK provides a more consistent user experience across all different platforms.

• Performance Monitoring: The Sentry Ruby SDK includes performance monitoring, which you can enable if you haven't already as (discussed here).

• Future Support: sentry-raven has entered maintenance mode, which means it won't receive any new features.

• Better Extensibility: Unlike sentry-raven, sentry-ruby is built with extensibility in mind and will allow the community to build extensions for different integrations/features.

sentry-ruby-v4.0.0

This is the first official release of Sentry's new Ruby SDKs.
Check our documentation to get started.
Take a look at the migration guide when upgrading from an older version.

If you are using the old sentry-raven client, here are the benefits of migrating to the new client:

• Unified Interfaces With Other SDKs: The design of sentry-raven is outdated compared with our modern Sentry SDKs. If you also use other Sentry SDKs, such as Sentry's JavaScript SDK for your frontend application, you'll notice that their interfaces are quite different from the one provided for sentry-raven. The new sentry-ruby SDK provides a more consistent user experience across all different platforms.

• Performance Monitoring: The Sentry Ruby SDK includes performance monitoring, which you can enable if you haven't already as (discussed here).

• Future Support: sentry-raven has entered maintenance mode, which means it won't receive any new features.

• Better Extensibility: Unlike sentry-raven, sentry-ruby is built with extensibility in mind and will allow the community to build extensions for different integrations/features.

sentry-rails-v4.0.0

This is the first official release of Sentry's new Ruby SDKs.
Check our documentation to get started.
Take a look at the migration guide when upgrading from an older version.

If you are using the old sentry-raven client, here are the benefits of migrating to the new client:

• Unified Interfaces With Other SDKs: The design of sentry-raven is outdated compared with our modern Sentry SDKs. If you also use other Sentry SDKs, such as Sentry's JavaScript SDK for your frontend application, you'll notice that their interfaces are quite different from the one provided for sentry-raven. The new sentry-ruby SDK provides a more consistent user experience across all different platforms.

• Performance Monitoring: The Sentry Ruby SDK includes performance monitoring, which you can enable if you haven't already as (discussed here).

• Future Support: sentry-raven has entered maintenance mode, which means it won't receive any new features.

• Better Extensibility: Unlike sentry-raven, sentry-ruby is built with extensibility in mind and will allow the community to build extensions for different integrations/features.