Bump sentry-tower from 0.35.0 to 0.47.0#805
Closed
dependabot[bot] wants to merge 1 commit intomasterfrom
Closed
Conversation
Bumps [sentry-tower](https://github.com/getsentry/sentry-rust) from 0.35.0 to 0.47.0. - [Release notes](https://github.com/getsentry/sentry-rust/releases) - [Changelog](https://github.com/getsentry/sentry-rust/blob/master/CHANGELOG.md) - [Commits](getsentry/sentry-rust@0.35.0...0.47.0) --- updated-dependencies: - dependency-name: sentry-tower dependency-version: 0.47.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
Contributor
Greptile SummaryThis PR bumps
Confidence Score: 1/5
|
| Filename | Overview |
|---|---|
| applications/data_manager/Cargo.toml | sentry-tower bumped to 0.47 while sentry remains at 0.35, causing a split in sentry-core versions that breaks the tower↔hub integration at runtime. |
| Cargo.lock | Lock file correctly reflects the version bump; the presence of both sentry-core 0.35.0 and sentry-core 0.47.0 in the dependency graph confirms the version mismatch. |
Prompt To Fix All With AI
This is a comment left during a code review.
Path: applications/data_manager/Cargo.toml
Line: 40-41
Comment:
**Mismatched `sentry` and `sentry-tower` versions break integration**
`sentry` is still at `0.35` while `sentry-tower` has been bumped to `0.47`. These two crates are part of the same ecosystem and must be kept in lockstep — as confirmed by the `Cargo.lock` diff, they now pull in two separate, incompatible versions of `sentry-core`:
- `sentry 0.35` → `sentry-core 0.35.0`
- `sentry-tower 0.47` → `sentry-core 0.47.0`
Because Rust treats these as entirely distinct crates at the type level, the global `Hub` initialized by `sentry 0.35` (via `sentry-core 0.35.0`) is invisible to `sentry-tower 0.47` (which calls `Hub::current()` on `sentry-core 0.47.0`). The tower middleware will operate against an uninitialized, no-op hub, silently discarding all request-level Sentry context (breadcrumbs, transaction/trace data, user info, etc.) instead of associating it with the configured Sentry client.
Either bump `sentry` to `0.47` to match, or revert `sentry-tower` back to `0.35` until a coordinated upgrade is ready.
```suggestion
sentry = { version = "0.47", features = ["tracing", "reqwest", "rustls"] }
sentry-tower = { version = "0.47", features = ["http"] }
```
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "Bump sentry-tower from 0.35.0 to 0.47.0" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
40
to
+41
| sentry = { version = "0.35", features = ["tracing", "reqwest", "rustls"] } | ||
| sentry-tower = { version = "0.35", features = ["http"] } | ||
| sentry-tower = { version = "0.47", features = ["http"] } |
Contributor
There was a problem hiding this comment.
sentry and sentry-tower versions break integration
sentry is still at 0.35 while sentry-tower has been bumped to 0.47. These two crates are part of the same ecosystem and must be kept in lockstep — as confirmed by the Cargo.lock diff, they now pull in two separate, incompatible versions of sentry-core:
sentry 0.35→sentry-core 0.35.0sentry-tower 0.47→sentry-core 0.47.0
Because Rust treats these as entirely distinct crates at the type level, the global Hub initialized by sentry 0.35 (via sentry-core 0.35.0) is invisible to sentry-tower 0.47 (which calls Hub::current() on sentry-core 0.47.0). The tower middleware will operate against an uninitialized, no-op hub, silently discarding all request-level Sentry context (breadcrumbs, transaction/trace data, user info, etc.) instead of associating it with the configured Sentry client.
Either bump sentry to 0.47 to match, or revert sentry-tower back to 0.35 until a coordinated upgrade is ready.
Suggested change
| sentry = { version = "0.35", features = ["tracing", "reqwest", "rustls"] } | |
| sentry-tower = { version = "0.35", features = ["http"] } | |
| sentry-tower = { version = "0.47", features = ["http"] } | |
| sentry = { version = "0.47", features = ["tracing", "reqwest", "rustls"] } | |
| sentry-tower = { version = "0.47", features = ["http"] } |
Prompt To Fix With AI
This is a comment left during a code review.
Path: applications/data_manager/Cargo.toml
Line: 40-41
Comment:
**Mismatched `sentry` and `sentry-tower` versions break integration**
`sentry` is still at `0.35` while `sentry-tower` has been bumped to `0.47`. These two crates are part of the same ecosystem and must be kept in lockstep — as confirmed by the `Cargo.lock` diff, they now pull in two separate, incompatible versions of `sentry-core`:
- `sentry 0.35` → `sentry-core 0.35.0`
- `sentry-tower 0.47` → `sentry-core 0.47.0`
Because Rust treats these as entirely distinct crates at the type level, the global `Hub` initialized by `sentry 0.35` (via `sentry-core 0.35.0`) is invisible to `sentry-tower 0.47` (which calls `Hub::current()` on `sentry-core 0.47.0`). The tower middleware will operate against an uninitialized, no-op hub, silently discarding all request-level Sentry context (breadcrumbs, transaction/trace data, user info, etc.) instead of associating it with the configured Sentry client.
Either bump `sentry` to `0.47` to match, or revert `sentry-tower` back to `0.35` until a coordinated upgrade is ready.
```suggestion
sentry = { version = "0.47", features = ["tracing", "reqwest", "rustls"] }
sentry-tower = { version = "0.47", features = ["http"] }
```
How can I resolve this? If you propose a fix, please make it concise.
Collaborator
|
This is being addressed in #799. |
Contributor
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps sentry-tower from 0.35.0 to 0.47.0.
Release notes
Sourced from sentry-tower's releases.
... (truncated)
Changelog
Sourced from sentry-tower's changelog.
... (truncated)
Commits
f638ca0release: 0.47.079ada42build(cargo): Runcargo update(#1030)e66f897meta(changelog): Prepare for release (#1029)d7a6da9ref(protocol): Generic items serializer (#1021)1795e4ameta(zed): Add project settings for Zed editor (#1019)fe351f6ref(sentry-core): Refactor logs batching into generic Batcher (#1018)0600229meta(ai): Remove trailing comma in.claude/settings.json(#1015)b913085fix!(core): Make HubSwitchGuard !Send to prevent thread corruption (#957)a819520build!: Updatereqwesttov0.13.1(#998)108c51dchore(repo): Add Claude Code settings with basic permissions (#959)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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill 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 versionwill 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 dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)