build(deps): bump sentry-panic from 0.38.1 to 0.45.0

[dependabot]

Bumps sentry-panic from 0.38.1 to 0.45.0.

Release notes

Sourced from sentry-panic's releases.

0.45.0

Breaking changes

• Add custom variant to AttachmentType that holds an arbitrary String. (#916)

0.44.0

Breaking changes

• feat(log): support combined LogFilters and RecordMappings (#914) by @​lcian
  • Breaking change: sentry::integrations::log::LogFilter has been changed to a bitflags struct.
  • It's now possible to map a log record to multiple items in Sentry by combining multiple log filters in the filter, e.g. log::Level::ERROR => LogFilter::Event | LogFilter::Log.
  • If using a custom mapper instead, it's possible to return a Vec<sentry::integrations::log::RecordMapping> to map a log record to multiple items in Sentry.

Behavioral changes

• ref(log): send logs by default when logs feature flag is enabled (#915) by @​lcian
  • If the logs feature flag is enabled, the default Sentry log logger now sends logs for all events at or above INFO.
• ref(logs): enable logs by default if logs feature flag is used (#910) by @​lcian
  • This changes the default value of sentry::ClientOptions::enable_logs to true.
  • This simplifies the setup of Sentry structured logs by requiring users to just add the log feature flag to the sentry dependency to opt-in to sending logs.
  • When the log feature flag is enabled, the tracing and log integrations will send structured logs to Sentry for all logs/events at or above INFO level by default.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

Features

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian

... (truncated)

Changelog

Sourced from sentry-panic's changelog.

0.45.0

Breaking changes

• Add custom variant to AttachmentType that holds an arbitrary String. (#916)

0.44.0

Breaking changes

• feat(log): support combined LogFilters and RecordMappings (#914) by @​lcian
  • Breaking change: sentry::integrations::log::LogFilter has been changed to a bitflags struct.
  • It's now possible to map a log record to multiple items in Sentry by combining multiple log filters in the filter, e.g. log::Level::ERROR => LogFilter::Event | LogFilter::Log.
  • If using a custom mapper instead, it's possible to return a Vec<sentry::integrations::log::RecordMapping> to map a log record to multiple items in Sentry.

Behavioral changes

• ref(log): send logs by default when logs feature flag is enabled (#915) by @​lcian
  • If the logs feature flag is enabled, the default Sentry log logger now sends logs for all events at or above INFO.
• ref(logs): enable logs by default if logs feature flag is used (#910) by @​lcian
  • This changes the default value of sentry::ClientOptions::enable_logs to true.
  • This simplifies the setup of Sentry structured logs by requiring users to just add the log feature flag to the sentry dependency to opt-in to sending logs.
  • When the log feature flag is enabled, the tracing and log integrations will send structured logs to Sentry for all logs/events at or above INFO level by default.

0.43.0

Breaking changes

• ref(tracing): rework tracing to Sentry span name/op conversion (#887) by @​lcian
  • The tracing integration now uses the tracing span name as the Sentry span name by default.
  • Before this change, the span name would be set based on the tracing span target (<module>::<function> when using the tracing::instrument macro).
  • The tracing integration now uses <span target>::<span name> as the default Sentry span op (i.e. <module>::<function> when using tracing::instrument).
  • Before this change, the span op would be set based on the tracing span name.
  • Read below to learn how to customize the span name and op.
  • When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
• ref(tracing): use standard code attributes (#899) by @​lcian
  • Logs now carry the attributes code.module.name, code.file.path and code.line.number standardized in OTEL to surface the respective information, in contrast with the previously sent tracing.module_path, tracing.file and tracing.line.
• fix(actix): capture only server errors (#877) by @​lcian
  • The Actix integration now properly honors the capture_server_errors option (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).
  • Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
  • With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
  • There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
• fix: send trace origin correctly (#906) by @​lcian
  • TraceContext now has an additional field origin, used to report which integration created a transaction.

Behavioral changes

• feat(tracing): send both breadcrumbs and logs by default (#878) by @​lcian
  • If the logs feature flag is enabled, and enable_logs: true is set on your client options, the default Sentry tracing layer now sends logs for all events at or above INFO.

... (truncated)

Commits

• aa6d85b release: 0.45.0
• b99eb46 feat(types): Add custom variant to AttachmentType (#916)
• 34b27b5 Merge branch 'release/0.44.0'
• eb108e8 release: 0.44.0
• 900ffa4 ref(logs): enable logs by default if logs feature flag is used (#910)
• 8af23ee ref(log): send logs by default when logs feature flag is enabled (#915)
• 3b78cf8 feat(log): support combined LogFilters and RecordMappings (#914)
• 9ba9a64 meta(vscode): Run rust-analyzer with all features (#902)
• 750dec0 ci: integrate Sentry Prevent (#911)
• d9cdf34 Merge branch 'release/0.43.0'
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)