chore(deps): update Dotnet SDK to v6.10.0 - #137
Conversation
0f8e21a to
45d8be2
Compare
45d8be2 to
bd6c516
Compare
bd6c516 to
ef9b094
Compare
| @@ -1,3 +1,3 @@ | |||
| version = 6.5.0 | |||
| version = 6.8.0 | |||
| repo = https://github.com/getsentry/sentry-dotnet | |||
There was a problem hiding this comment.
Bug: The dependency upgrade to Sentry .NET SDK v6.8.0 may break reflection-based access to internal APIs like HttpTransportBase.ProcessEnvelope, causing initialization failures.
Severity: HIGH
Suggested Fix
Verify that the internal Sentry .NET SDK APIs accessed via reflection still exist and have the same signatures in v6.8.0. If they have changed, update the reflection code in SynchronousTransport.ps1 and New-HttpTransport.ps1 to match the new API. Consider adding tests that validate the reflection against the new SDK version to prevent future breakages.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: dependencies/Sentry.properties#L2
Potential issue: The `sentry-powershell` module uses reflection to access internal,
non-public APIs of the Sentry .NET SDK, including `HttpTransportBase.ProcessEnvelope`,
`HttpTransportBase.CreateRequest`, and `SdkComposer.CreateHttpTransport()`. This pull
request upgrades the SDK from v6.5.0 to v6.8.0. There is a risk that these internal
APIs, which are not part of the public contract, have changed between versions. If they
have, the reflection calls will fail during `Start-Sentry` initialization, throwing an
exception. This will be logged as a warning and may either cause the script to fail or
continue without the custom synchronous transport, depending on the
`SentryPowershellRethrowErrors` global flag.
Did we get this right? 👍 / 👎 to inform future reviews.
ef9b094 to
a926a1d
Compare
a926a1d to
5ee2fec
Compare
5ee2fec to
3fc09af
Compare
sentry-dotnet 6.10.0 removed the EnableLogs gate on SentrySdk.Logger, which is what Write-SentryLog calls. Setting $_.EnableLogs = $true no longer has any bearing on whether Write-SentryLog emits, so the sample's "opt in to Logs" guidance now teaches something untrue. Verified against the bundled 6.10.0 assembly: a log envelope item reaches the transport with EnableLogs both set and unset, where 6.5.0 emitted only when it was set. No test covers the disabled path, which is why the change was invisible to CI. Co-Authored-By: Claude Opus 5 <[email protected]>
|
Reviewed the bump and pushed a small doc fix (4785f72). Summary of what was verified locally against the 6.10.0 package: Package / build wiring
Reflection contract Behaviour change worth knowing about
So Tests: full Pester suite green against 6.10.0 locally (macOS, pwsh 7.5.4) — 95 passed, 0 failed, 3 skipped. Unrelated to this PR, but found while auditing the reflection sites: |
Write-SentryLog and the SDK bump that removed the EnableLogs gate both land in the same unreleased cycle, so describing the removal as its own entry documents a change no released version ever exposed. Readers of the next release only need to know the cmdlet exists, so reference #137 from the entry that introduced it instead. Drop the EnableLogs half of the breaking-changes entry for the same reason: it directed readers to set $_.EnableLogs, which is no longer required for Write-SentryLog to emit. Co-Authored-By: Claude Opus 5 <[email protected]>
Write-SentryLog (#131) and the move of its options off Experimental (#133) both land in this same unreleased cycle, so no released version ever exposed $_.Experimental.SetBeforeSendLog through the module. There is nothing for a user upgrading from 0.4.0 to migrate. Reaching past the module into the bundled SDK's options object was the only way to touch it from 0.4.0, and the Dependencies entry for the 5.16.1 -> 6.10.0 bump already covers that surface. Co-Authored-By: Claude Opus 5 <[email protected]>
#133 moved the Logs options off Experimental and updated the sample and tests accordingly, so it shaped the logging surface users see. Its attribution lived in the breaking-change entry that was just removed; fold it into the feature entry rather than losing it. Co-Authored-By: Claude Opus 5 <[email protected]>
|
FYI @jamescrosswell I've appended some changelog/docs cleanups here. |
Bumps dependencies/Sentry.properties from 6.5.0 to 6.10.0.
Auto-generated by a dependency updater.
Changelog
6.10.0
Features ✨
SentrySdk.Loggerno longer requireEnableLogsby jamescrosswell in #5512SentryOptions.EnableMetricsis obsolete and ignored by jamescrosswell in #5509Fixes 🐛
Dependencies ⬆️
Deps
Other
6.9.0
Features ✨
Fixes 🐛
Dependencies ⬆️
Deps
Other
6.8.0
Features ✨
Logs
log4netintegration by Flash0ver in #5172NLogintegration by Flash0ver in #5176Other
AddToTransactionsonSentryAttachment#5182 by jamescrosswell in #5182SentrySdk.RecordTransactionto record already-completed transactions and spans (e.g. replayed through a proxy) #5333 by jamescrosswell in #5333Environmentset on theScopenow gets synchronized to the native layers (sentry-cocoaandsentry-native) by bitsandfoxes in #5365Fixes 🐛
SentrySpanProcessorno longer leaks spans whose Activity never ends (e.g. aborted requests); the Activity is now held via aWeakReferenceso orphaned spans are pruned once it is garbage-collected. by Ermabo in #5393Dependencies ⬆️
Deps
Other
6.7.0
Features ✨
IgnoreTransactionsoption to filter out transactions by name, matching substrings or regular expressions against the transaction name (#5377) by Adham-Kiwan in #5377SentryEventExtensions.IsFromUnhandledException) and terminal exceptions (SentryEventExtensions.IsFromTerminalException) by jamescrosswell in #5177Fixes 🐛
Dependencies ⬆️
Deps
Other
Sentry.Extensions.LoggingFilters by Flash0ver in #52976.6.0
Features ✨
sentry-androidandsentry-cocoaby bitsandfoxes in #5244Fixes 🐛
Dependencies ⬆️
Deps
Other