Conversation
Bumps [sentry](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 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
Greptile SummaryDependabot bumps
Confidence Score: 1/5
|
| Filename | Overview |
|---|---|
| applications/data_manager/Cargo.toml | Bumps sentry to 0.47 but leaves sentry-tower at 0.35, causing a sentry-core version split that silently breaks the tower middleware integration. Also introduces duplicate reqwest versions (0.12 + 0.13). |
| Cargo.lock | Auto-generated lockfile reflecting the sentry 0.47 upgrade. Contains dual sentry-core (0.35 + 0.47) and dual reqwest (0.12 + 0.13) resolutions due to the sentry-tower version mismatch. |
Comments Outside Diff (1)
-
applications/data_manager/Cargo.toml, line 25 (link)Dual
reqwestversions pulled into binarysentry0.47 depends onreqwest0.13.x (confirmed in Cargo.lock asreqwest 0.13.2), while this project pinsreqwest = "0.12.23"for its own HTTP calls. Cargo resolves these as two separate crates, increasing binary size and duplicating TLS/connection-pool overhead. This won't cause a compilation error, but it's wasteful and could be confusing when debugging networking issues.Consider bumping the project's direct
reqwestdependency to 0.13 to unify the dependency tree, or verify that 0.12 is intentionally kept for compatibility with other crates (e.g., the dev-dependency on line 48).Prompt To Fix With AI
This is a comment left during a code review. Path: applications/data_manager/Cargo.toml Line: 25 Comment: **Dual `reqwest` versions pulled into binary** `sentry` 0.47 depends on `reqwest` 0.13.x (confirmed in Cargo.lock as `reqwest 0.13.2`), while this project pins `reqwest = "0.12.23"` for its own HTTP calls. Cargo resolves these as two separate crates, increasing binary size and duplicating TLS/connection-pool overhead. This won't cause a compilation error, but it's wasteful and could be confusing when debugging networking issues. Consider bumping the project's direct `reqwest` dependency to 0.13 to unify the dependency tree, or verify that 0.12 is intentionally kept for compatibility with other crates (e.g., the dev-dependency on line 48). How can I resolve this? If you propose a fix, please make it concise.
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:
**`sentry-tower` must be bumped to match `sentry`**
`sentry` is bumped to 0.47 but `sentry-tower` remains at 0.35. These two crates depend on different, incompatible versions of `sentry-core` — the Cargo.lock confirms both `sentry-core` 0.35.0 and `sentry-core` 0.47.0 are resolved as separate crates. This means the `SentryHttpLayer::with_transaction()` used in `router.rs:32` operates on the 0.35 Hub, while `sentry::init()` in `startup.rs:8` initializes the 0.47 Hub. The tower middleware will silently become a no-op: it won't capture transactions or attach request data to Sentry events.
`sentry-tower` 0.47.0 is available on crates.io and depends on `sentry-core ^0.47.0`. Bump it to match:
```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.
---
This is a comment left during a code review.
Path: applications/data_manager/Cargo.toml
Line: 25
Comment:
**Dual `reqwest` versions pulled into binary**
`sentry` 0.47 depends on `reqwest` 0.13.x (confirmed in Cargo.lock as `reqwest 0.13.2`), while this project pins `reqwest = "0.12.23"` for its own HTTP calls. Cargo resolves these as two separate crates, increasing binary size and duplicating TLS/connection-pool overhead. This won't cause a compilation error, but it's wasteful and could be confusing when debugging networking issues.
Consider bumping the project's direct `reqwest` dependency to 0.13 to unify the dependency tree, or verify that 0.12 is intentionally kept for compatibility with other crates (e.g., the dev-dependency on line 48).
How can I resolve this? If you propose a fix, please make it concise.Last reviewed commit: 0a390ad
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| sentry = { version = "0.47", features = ["tracing", "reqwest", "rustls"] } | ||
| sentry-tower = { version = "0.35", features = ["http"] } |
There was a problem hiding this comment.
sentry-tower must be bumped to match sentry
sentry is bumped to 0.47 but sentry-tower remains at 0.35. These two crates depend on different, incompatible versions of sentry-core — the Cargo.lock confirms both sentry-core 0.35.0 and sentry-core 0.47.0 are resolved as separate crates. This means the SentryHttpLayer::with_transaction() used in router.rs:32 operates on the 0.35 Hub, while sentry::init() in startup.rs:8 initializes the 0.47 Hub. The tower middleware will silently become a no-op: it won't capture transactions or attach request data to Sentry events.
sentry-tower 0.47.0 is available on crates.io and depends on sentry-core ^0.47.0. Bump it to match:
| sentry = { version = "0.47", features = ["tracing", "reqwest", "rustls"] } | |
| sentry-tower = { version = "0.35", 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:
**`sentry-tower` must be bumped to match `sentry`**
`sentry` is bumped to 0.47 but `sentry-tower` remains at 0.35. These two crates depend on different, incompatible versions of `sentry-core` — the Cargo.lock confirms both `sentry-core` 0.35.0 and `sentry-core` 0.47.0 are resolved as separate crates. This means the `SentryHttpLayer::with_transaction()` used in `router.rs:32` operates on the 0.35 Hub, while `sentry::init()` in `startup.rs:8` initializes the 0.47 Hub. The tower middleware will silently become a no-op: it won't capture transactions or attach request data to Sentry events.
`sentry-tower` 0.47.0 is available on crates.io and depends on `sentry-core ^0.47.0`. Bump it to match:
```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.
…, #798 Updated direct dependencies in applications/data_manager/Cargo.toml: - sentry 0.35 -> 0.47 and sentry-tower 0.35 -> 0.47: large jump across multiple releases; CI passed on the Dependabot PR confirming no breaking API usage. Updated SentryHttpLayer::with_transaction() (deprecated since 0.38) to SentryHttpLayer::new().enable_transaction() in router.rs. - duckdb 1.4.3 -> 1.10500.0: new versioning scheme (encodes bundled DuckDB v1.5.0). The Dependabot PR had a CI failure; build and all 18 tests pass locally with the updated version. - aws-config 1.5 -> 1.8.15 and aws-credential-types 1.2.13 -> 1.2.14: patch updates with no breaking changes. Transitive security fixes pulled in via Cargo.lock regeneration: - quinn-proto 0.11.13 -> 0.11.14: fixes DoS vulnerability GHSA-6xvm-j4wr-6v98 - tar 0.4.44 -> 0.4.45: fixes symlink-directory collision chmod attack Closes #788, #789, #794, #795, #798 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Addressed in pull request #799. |
|
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. |
1 participant
Bumps sentry from 0.35.0 to 0.47.0.
Release notes
Sourced from sentry's releases.
... (truncated)
Changelog
Sourced from sentry'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)