Repository navigation
Update v9 branch - #6453
Update v9 branch#6453sentry-junior[bot] wants to merge 41 commits into
Conversation
…ain (#6291) * fix(profiling): Cancel a pending stop when the profiler is started again A stop request only sets shouldStop, and the profiler stops when the current chunk ends. A start call before that was ignored because the profiler was still running, and shouldStop stayed set. So the profiler stopped at the end of the chunk, even in TRACE mode while sampled spans were active. The legacy profiler also never reset shouldStop, so after the first stop every later profile ended after one chunk. Reset shouldStop on every sampled start call in AndroidContinuousProfiler and PerfettoContinuousProfiler. A manual start while the profiler runs is now an expected call, so the Perfetto profiler logs it at DEBUG level like the legacy profiler. * changelog * docs(changelog): Move the profiler restart entry to Unreleased 8.61.1 was released after the branch was created, so the rebase landed the entry inside the released section. Move it back under a new Unreleased heading.
Co-Authored-By: Chris Aigner <christoph.aigner@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
The current wordmark is dark on a transparent background, so it is nearly illegible when GitHub is in dark mode. Wrap the logo in a `<picture>` element that serves `sentry-logo-white.png` for `prefers-color-scheme: dark` and the purple `sentry-wordmark-dark-280x84.png` otherwise. The plain `<img>` fallback keeps renderers without `<picture>` support working. Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Daniel Szoke <daniel.szoke@sentry.io>
…4.0 (#6403) Bumps androidx.recyclerview:recyclerview from 1.2.1 to 1.4.0. --- updated-dependencies: - dependency-name: androidx.recyclerview:recyclerview dependency-version: 1.4.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* chore(deps): bump com.abovevacant:epitaph from 0.1.1 to 0.2.0 Bumps [com.abovevacant:epitaph](https://github.com/abovevacant/epitaph) from 0.1.1 to 0.2.0. - [Changelog](https://github.com/abovevacant/epitaph/blob/main/CHANGELOG.md) - [Commits](abovevacant/epitaph@v0.1.1...v0.2.0) --- updated-dependencies: - dependency-name: com.abovevacant:epitaph dependency-version: 0.2.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * changelog Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Nelson Osacky <nelson.osacky@sentry.io>
* build: Move from the binary-compatibility-validator plugin to KGP ABI validation * build: Validate the ABI of sentry-opentelemetry-agentless Co-Authored-By: Markus Hintersteiner <markus.hintersteiner@sentry.io> * build: Drop the apiDump and apiCheck aliases in favour of the KGP task names * build: Restore the root build file changes from main lost in the merge * build: Chain the ABI filters onto the abiValidation lookup --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
…6406) BaseExtension is deprecated in AGP 9 and removed in AGP 10, and it is not the registered android extension once android.newDsl=true. The DSL LibraryExtension exposes the same compileOptions and aarMetadata blocks and works with both DSL modes. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* added get/set environment to scope * updated changelog * updated changelog * sync scope clear * clear * apply to replay * scope helper * comment * made scope apply its environment on other events too * Update CHANGELOG.md Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com> * feat: apply the scope environment to Baggage/DSC and address review feedback * fix: read the DSC environment from the combined scope view instead of the isolation scope * feat: apply the scope environment to logs, metrics and profiles * test: stub the ScopeType overload of configureScope in scopes mocks * feat(android): sync the scope environment to the NDK scope * ci: fix Build Job ubuntu-latest [pr-shepherd] * test(apollo-5): stub the ScopeType overload of configureScope in scopes mock * chore: move changelog entry to Unreleased * fix(ndk): catch only RejectedExecutionException when syncing the scope environment --------- Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com> Co-authored-by: Markus Hintersteiner <markus.hintersteiner@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
… the test matrix (#6381) * test(spring-boot): Drop Spring Boot 2.4 to 2.6 from the test matrix Spring Boot 2.4 to 2.6 are long past end of life. They were the only reason the Boot 2 suites left GraphQL and Kafka out of their compilation below 2.7, which stands in the way of compiling the suites once and running them on each Boot version's classpath (JAVA-802). The Kafka beans stay in a profile, so only the Kafka tests need a broker. Co-Authored-By: Claude <noreply@anthropic.com> * test(spring): [Sample Tests 42] Run each Spring Boot matrix version as its own Gradle task (#6382) * test(spring): Run each Spring Boot matrix version as its own Gradle task The Spring Boot matrix workflows tested each version by rewriting the catalog with perl, so a version could only be tested locally by editing the catalog, and every job recompiled the SDK and the suites. The new io.sentry.spring-boot-matrix plugin registers a test task per suite and version, e.g. integrationTestWebfluxBoot3_2_12. It reuses the suite's compiled classes on a runtime classpath resolved for that version, which swaps every org.springframework.boot artifact, the BOM included, as the catalog edit did. The resolved classpaths match the catalog edit's exactly. So the SDK and the suites now compile once, against the catalog's version, and only the runtime varies, which is how users run our jars. Suite code may only use APIs of the oldest version of its line. allIntegrationTestsBoot<version> runs one version's suites in a module, and allIntegrationTestsBoot<major> every version's. Each workflow runs the latter from the root in one job per Boot line, with --continue so a failing version doesn't hide the others. The versions live only in SpringBootVersions in build-logic. Resolves JAVA-802 Co-Authored-By: Claude <noreply@anthropic.com> * test(spring): Run each Spring Boot version in its own CI job One job per Boot line doubled the matrix wall time, e.g. 12.5 minutes instead of about 6 for Boot 3. A single runner ran every version's suites, and the bare task name made Gradle configure every project to find it. The versions move to gradle/spring-boot-versions.json. build-logic reads it, and each workflow turns its line into one job per version, which runs that version's aggregate in both modules by project path. The version list stays in one place, and the check names match main's again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(spring): Create the Spring Boot matrix classpaths as resolvable configurations They're only ever resolved, so configurations.resolvable() fits them better than create() with isCanBeConsumed = false: nothing can consume them or declare dependencies on them. Every matrix classpath resolves the same as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub <noreply@github.com>
Fix issues the review of the sample tests stack found in the new in-module end-to-end tests: - MockSentryServer keeps the error when it can't read a body and rethrows it while waiting, so a serialization bug no longer looks like a missing envelope. - ChildJvmApp only takes a port that two reads agree on. A partly written port such as "54" of "54321" parsed and pointed the test at the wrong port. - The agentless test starts a span through the OpenTelemetry API and checks that it reaches Sentry. Before, it passed with the OpenTelemetry wiring broken. - The Person tests use id 11 and match their transaction by URL, so envelopes from the tracing tests' /person/1 calls can't satisfy them. - The Boot 2 Kafka test shares the suite's context and broker, as on Boot 3 and 4. Its second context re-ran Sentry.init and made later tests depend on the run order. Boot 2.4 to 2.6 were the reason for the split and are gone. - Tests fail clearly when a system property the Gradle task sets is missing, rather than running with -javaagent:null. - Remove the Boot 2 version gating from the samples, the runner's files from .gitignore, and the unused jackson-kotlin entry. Co-authored-by: Nelson Osacky <nelson.osacky@sentry.io>
* perf(replay): Use hash set for mask view class lookups maskViewClasses and unmaskViewClasses were backed by a CopyOnWriteArraySet, whose contains() is a linear scan. The view hierarchy traversal checks both sets for every superclass of every view on the main thread, so capture cost grew with the size of the configured class lists. Back both sets with a ConcurrentHashMap key set for O(1) lookups while keeping thread-safe, non-throwing iteration. Co-Authored-By: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> * changelog Co-Authored-By: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> * fix(replay): Ignore null mask view class names ConcurrentHashMap-backed sets reject null keys, while the previous CopyOnWriteArraySet accepted them. Hybrid SDKs (e.g. React Native via ReadableArray.getString) can pass null despite the @NotNull annotation, which would now throw during SDK init. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> Co-authored-by: Roman Zavarnitsyn <rom4ek93@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…polloInterceptor (#6414) * feat(apollo): Add a flag to stop attaching tracing headers in SentryApolloInterceptor * changelog * fix(apollo): Preserve interceptor constructor compatibility Keep the existing Kotlin default-argument constructor ABI while exposing the tracing-header opt-out through a secondary constructor. This prevents runtime linkage failures for precompiled consumers upgrading the SDK. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Alexander Dinauer <adinauer@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
) Bumps [org.quartz-scheduler:quartz](https://github.com/quartz-scheduler/quartz) from 2.3.0 to 2.5.2. - [Release notes](https://github.com/quartz-scheduler/quartz/releases) - [Commits](quartz-scheduler/quartz@quartz-2.3.0...v2.5.2) --- updated-dependencies: - dependency-name: org.quartz-scheduler:quartz dependency-version: 2.5.2 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the github-actions group with 1 update: [getsentry/craft](https://github.com/getsentry/craft). Updates `getsentry/craft` from 3.0.0 to 3.3.0 - [Release notes](https://github.com/getsentry/craft/releases) - [Changelog](https://github.com/getsentry/craft/blob/master/CHANGELOG.md) - [Commits](getsentry/craft@924b450...4b763f5) --- updated-dependencies: - dependency-name: getsentry/craft dependency-version: 3.3.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…6412) Bumps [com.vanniktech.maven.publish](https://github.com/vanniktech/gradle-maven-publish-plugin) from 0.30.0 to 0.37.0. - [Release notes](https://github.com/vanniktech/gradle-maven-publish-plugin/releases) - [Changelog](https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/CHANGELOG.md) - [Commits](vanniktech/gradle-maven-publish-plugin@0.30.0...0.37.0) --- updated-dependencies: - dependency-name: com.vanniktech.maven.publish dependency-version: 0.37.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* fix(transport): Reject leaked eMudhra intermediate certificates The private keys of eight eMudhra intermediates can be recovered from their certificates (CVE-2026-111943). Their Sectigo cross-signs chain to AAA Certificate Services, which is trusted on every Android version, so platform trust store updates won't reach every device. The envelope transport and the distribution client now reject servers that present one of these keys, right after the TLS handshake and before any request is written. Fixes JAVA-783 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog * ref(transport): Pass DistrustedCertificates to HttpConnection Inject the check through HttpConnection's constructor like AuthenticatorWrapper, so its tests can stub it instead of loading the real eMudhra certificate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(transport): Check distrusted eMudhra CAs on every TLS handshake Checking the server certificates once after connect() missed the new connections HttpURLConnection opens on its own to retry a request, and chains Android completes from intermediates cached on earlier connections. Wrap the SSLSocketFactory so every handshake is checked, and match the leaf's issuer by name. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog: Shorten the eMudhra entry Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog: Move the eMudhra entry to Unreleased Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Bumps the github-actions group with 2 updates: [gradle/actions/setup-gradle](https://github.com/gradle/actions) and [getsentry/craft](https://github.com/getsentry/craft). Updates `gradle/actions/setup-gradle` from 6.4.0 to 6.4.1 - [Release notes](https://github.com/gradle/actions/releases) - [Commits](gradle/actions@3f5f9ad...8da46b5) Updates `getsentry/craft` from 3.3.0 to 3.4.1 - [Release notes](https://github.com/getsentry/craft/releases) - [Changelog](https://github.com/getsentry/craft/blob/master/CHANGELOG.md) - [Commits](getsentry/craft@4b763f5...90e8e20) --- updated-dependencies: - dependency-name: gradle/actions/setup-gradle dependency-version: 6.4.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: getsentry/craft dependency-version: 3.4.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps com.gradle.develocity from 4.5.0 to 4.6.1. --- updated-dependencies: - dependency-name: com.gradle.develocity dependency-version: 4.6.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The repository has had no submodules since the NDK moved to sentry-native (#3189), which left `.gitmodules` empty. The `submodules: 'recursive'` input on our checkout steps has been a no-op since, so drop it along with the empty file. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Drop cache-encryption-key and GRADLE_ENCRYPTION_KEY from all workflows, and the buildSrc cache step that worked around gradle/actions#21. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…is off (#6401) The sample cancelled the Activity's ui.load transaction through the scope. When another transaction was already bound, such as the previous Activity's nav transaction, the SDK didn't bind ui.load, so the cancel missed and the transaction was still sent, often waiting the full deadline with the Activity's spans. Keep cancelling a bound ui.load transaction so it doesn't block the first nav transaction, and also drop Nav3 sample Activities' ui.load transactions in an event processor when the Activity was created with the toggle off. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
) * fix(android): Skip dist fallback when release has no version code ApplicationExitInfoEventProcessor derived dist from the text after '+' in the release. Without a '+', indexOf returned -1 and the whole release became dist, which Relay rejects for characters like '@'. Co-Authored-By: Gene Wright <gene.wright@sentry.io> * changelog Co-Authored-By: Gene Wright <gene.wright@sentry.io> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Gene Wright <gene.wright@sentry.io>
* fix(anr): Skip ANR profiling while a debugger is connected * changelog * ref(anr): Provide debugger detection through SentryOptions
* ci(release): Bump getsentry/craft to 3.9.0 3.9.0 includes getsentry/craft#956, which stops the release when release-blocker issues are open. * ci(release): Update .craft.yml for craft 3.9.0 Co-Authored-By: BYK <126780+BYK@users.noreply.github.com> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: BYK <126780+BYK@users.noreply.github.com>
Two production ANRs in the Android SDK came from holding a lock across a call that re-enters the SDK: finishing a span or transaction captures synchronously on the calling thread and runs every event processor, and those processors lock and call back into the component that is still holding its own lock. Write the rule down next to the exception-handling guidance, with the snapshot-then-call pattern, the second-lock escape hatch for compound operations that were only atomic because the lock spanned them, and the volatile and single-read rules. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Make the multi-Activity and multi-Fragment support introduced by the #6301 PR stack play nicely with ViewPager2. BACKGROUND The approach in #6301 was smart about staging nav data (ie, screen name + nav context), but it didn't do the same for nav transactions. A new nav transaction could be started only if the lease was owned at the time of navigation, where "navigation" == initialization or modification of the nav back stack. Because the lease had to be owned, that meant that the Activity or Fragment hosting the SentryNavEffect requesting the lease had to be in a resumed state. That^^ assumption made sense for most use cases, because usually initialization of an Activity or Fragment's nav back stack coincides with the Activity or Fragment being visible and therefore being able to preempt the lease from the previous leaseholder. But the assumption didn't pan out for ViewPager2, because ViewPager2 preloads neighboring pages. That means it initializes the nav back stack for Fragments that aren't in a resumed state and therefore can't preempt the lease, causing them to drop their initial nav transaction and any spans created by the initial destination screen. Sigh. THE SOLUTION The solution this commit implements is to create a mechanism similar to the data staging from #6301, but for transactions. Doing so lets us separate back stack initialization observed during preloading vs attempted lease acquisition when a ViewPager2 page becomes visible. In particular, the new StagedNavTransaction class tracks requests to start nav transactions when a SentryNavEffect is created even if it doesn't currently have the lease. If the lease is later acquired and the transaction slot is available on the shared IScope, the staged transaction is started, which keeps ViewPager2 happy. REFACTORING INCLUDED Included in this commit is a refactor of code in the .navigation3.lifecycle package. The refactor lets us separate three responsibilities: - Lease coordination: NavLeaseCoordinator observes registered owners’ lifecycles and decides which SentryNavEffect may publish navigation state. - State publication: Each effect’s NavScopes publishes and withdraws its navigation data and transaction together when ownership changes. - Transaction management: Each effect gets a transaction handle that manages starting, finishing, binding, and restoring its transaction. The coordinator no longer retains transactions itself.
…til their deadline (JAVA-795) (#6396) An idle span (SpanOptions.isIdle) is meant to be finished by its parent transaction when the transaction finishes. Before this commit, SentryTracer treated an unfinished idle span as blocking. Creating one canceled the idle timer; SentryTracer.hasAllChildrenFinished() counted it as unfinished; and the timer never restarted. As a consequence, any idle transaction that i) waited for its children (i.e., all Android idle transactions, including ui.load and nav transactions) and ii) had an unfinished idle span was kept alive until its deadline (30 s by default), causing it to be reported as DEADLINE_EXCEEDED even though in most cases no actual work was keeping the transaction alive. **Current producers of idle spans** SentryTraced is the SDK's only producer of idle spans, so the effects mentioned above are limited to idle transactions that, prior to this commit, contained a span from SentryTraced. (The issue has been with SentryTraced from the beginning – see #2507).
Bumps [io.coil-kt:coil-compose](https://github.com/coil-kt/coil) from 2.6.0 to 2.7.0. - [Release notes](https://github.com/coil-kt/coil/releases) - [Changelog](https://github.com/coil-kt/coil/blob/main/CHANGELOG.md) - [Commits](coil-kt/coil@2.6.0...2.7.0) --- updated-dependencies: - dependency-name: io.coil-kt:coil-compose dependency-version: 2.7.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: GitHub <noreply@github.com>
* build: Assemble dist zips from a local Maven repo layout Craft expects Maven file names in each dist dir, e.g. <artifactId>-<version>-javadoc.jar. We used to copy build outputs and rename them to match, so the rules broke whenever a plugin changed its output names. The vanniktech maven-publish 0.30.0 -> 0.37.0 bump (#6412) added the version to the KMP javadoc jars, so sentry-compose-<version>-javadoc.jar was missing and the 8.63.0 publish failed. Now every module also publishes to build/distMaven and the dist zips copy from its Maven layout, where file names are fixed by Maven itself. Only the craft-specific names are renamed (pom-default.xml, -release.aar). The zip contents are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ref(build): Make distMavenDir an extension property Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* docs: Announce Java 11 and minSdk 26 requirements for SDK 9 Add a warning at the top of the changelog that SDK 9.0.0 drops Java 8 and raises the Android minSdk from 21 to 26, linking to the feedback issues so users can raise concerns before the major release. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: Drop the stay-on-8.x line from the SDK 9 warning Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…figs (#6217) * ref(core): Add MonitorConfigUtils to convert schedules to monitor configs Framework-free conversion of a 6 field cron expression, fixed rate or fixed delay into a MonitorConfig, plus period parsing, so the Spring and Quartz integrations can share it. * fix(core): Only send monitor configs Sentry reads the same way Return no config when day of month and day of week are both set, for cron syntax Sentry rejects, and for zones that are not IANA region IDs. Whole-hour fixed offsets map to Etc/GMT zones. Intervals use hours or days when they divide evenly. * ref(core): Add MonitorConfigUtils.fromSpringScheduled Move the Spring day-of-week rewrite and the JVM default zone rule into core so the three Spring modules share them. * fix(core): Return no config for stepped single value ranges Spring and Quartz run 10-10/2 only at 10, cronsim steps to the field max. * fix(core): Read Spring crons per parser and skip fixed delays Spring before 5.3 steps day of month */n from 0 and can run at midnight when both day fields are set; read its crons that way. Spring 5.3 runs #5 in months without a fifth weekday, so return null for it. A fixed delay drifts from any interval, so it gets no config. * fix(core): Keep Sunday-only day of week ranges SUN-SUN was rewritten to 0-7, which crontab reads as every day. Co-Authored-By: Claude <noreply@anthropic.com> * fix(core): Use a 2 minute check-in margin for crons with fixed seconds Dropping a non-zero seconds field makes check-ins arrive up to 59s after the expected minute, which a 1 minute margin barely covers. --------- Co-authored-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9b8318e. Configure here.
| } | ||
| return new MonitorConfig(MonitorSchedule.interval((int) value, unit)); | ||
| } | ||
| return null; |
There was a problem hiding this comment.
Disabled cron blocks interval monitors
High Severity
fromSchedule treats - as a present cron, so a disabled Spring cron plus a fixedRate is rejected as two schedule kinds. Spring uses - (Scheduled.CRON_DISABLED, and the @Scheduled default on Spring 6+) to mean cron is unset and the rate should be used. toCrontab already drops -, but that path is skipped when an interval is also passed, so fromSpringScheduled returns no config for ordinary fixed-rate jobs.
Additional Locations (2)
Triggered by project rule: PR Review Guidelines for Cursor Bugbot
Reviewed by Cursor Bugbot for commit 9b8318e. Configure here.
…#6215) * ref(core): Add MonitorConfigUtils to convert schedules to monitor configs Framework-free conversion of a 6 field cron expression, fixed rate or fixed delay into a MonitorConfig, plus period parsing, so the Spring and Quartz integrations can share it. * fix(core): Only send monitor configs Sentry reads the same way Return no config when day of month and day of week are both set, for cron syntax Sentry rejects, and for zones that are not IANA region IDs. Whole-hour fixed offsets map to Etc/GMT zones. Intervals use hours or days when they divide evenly. * ref(core): Add MonitorConfigUtils.fromSpringScheduled Move the Spring day-of-week rewrite and the JVM default zone rule into core so the three Spring modules share them. * fix(core): Return no config for stepped single value ranges Spring and Quartz run 10-10/2 only at 10, cronsim steps to the field max. * fix(core): Read Spring crons per parser and skip fixed delays Spring before 5.3 steps day of month */n from 0 and can run at midnight when both day fields are set; read its crons that way. Spring 5.3 runs #5 in months without a fifth weekday, so return null for it. A fixed delay drifts from any interval, so it gets no config. * feat(spring): Send monitor config from @scheduled with @SentryCheckIn Co-Authored-By: Claude <noreply@anthropic.com> * feat(spring): Send @scheduled monitor config by default Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * fix(core): Keep Sunday-only day of week ranges SUN-SUN was rewritten to 0-7, which crontab reads as every day. Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring): Only catch runtime exceptions when deriving monitor config Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Use pattern-matching instanceof for the @scheduled time unit * fix(core): Use a 2 minute check-in margin for crons with fixed seconds Dropping a non-zero seconds field makes check-ins arrive up to 59s after the expected minute, which a 1 minute margin barely covers. * fix(spring): Default upsertMonitorConfig to false and read @scheduled like Spring Existing @SentryCheckIn users shouldn't have their monitors changed on upgrade, so sending the schedule is opt-in. Find @scheduled with Spring's own lookup so an overriding method doesn't inherit a parent's schedule. * chore(changelog): Move the @scheduled monitor config entry to Unreleased --------- Co-authored-by: Claude <noreply@anthropic.com>
) * ref(core): Add MonitorConfigUtils to convert schedules to monitor configs Framework-free conversion of a 6 field cron expression, fixed rate or fixed delay into a MonitorConfig, plus period parsing, so the Spring and Quartz integrations can share it. * fix(core): Only send monitor configs Sentry reads the same way Return no config when day of month and day of week are both set, for cron syntax Sentry rejects, and for zones that are not IANA region IDs. Whole-hour fixed offsets map to Etc/GMT zones. Intervals use hours or days when they divide evenly. * ref(core): Add MonitorConfigUtils.fromSpringScheduled Move the Spring day-of-week rewrite and the JVM default zone rule into core so the three Spring modules share them. * fix(core): Return no config for stepped single value ranges Spring and Quartz run 10-10/2 only at 10, cronsim steps to the field max. * fix(core): Read Spring crons per parser and skip fixed delays Spring before 5.3 steps day of month */n from 0 and can run at midnight when both day fields are set; read its crons that way. Spring 5.3 runs #5 in months without a fifth weekday, so return null for it. A fixed delay drifts from any interval, so it gets no config. * feat(spring): Send monitor config from @scheduled with @SentryCheckIn Co-Authored-By: Claude <noreply@anthropic.com> * feat(quartz): Send monitor config from the trigger with check-ins Co-Authored-By: Claude <noreply@anthropic.com> * feat(spring): Send @scheduled monitor config by default Co-Authored-By: Claude <noreply@anthropic.com> * feat(quartz): Send trigger monitor config by default Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * fix(core): Keep Sunday-only day of week ranges SUN-SUN was rewritten to 0-7, which crontab reads as every day. Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring): Only catch runtime exceptions when deriving monitor config Co-Authored-By: Claude <noreply@anthropic.com> * fix(quartz): Catch only expected errors when deriving monitor config Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Use pattern-matching instanceof for the @scheduled time unit * fix(core): Use a 2 minute check-in margin for crons with fixed seconds Dropping a non-zero seconds field makes check-ins arrive up to 59s after the expected minute, which a 1 minute margin barely covers. * fix(spring): Default upsertMonitorConfig to false and read @scheduled like Spring Existing @SentryCheckIn users shouldn't have their monitors changed on upgrade, so sending the schedule is opt-in. Find @scheduled with Spring's own lookup so an overriding method doesn't inherit a parent's schedule. * fix(quartz): Send the trigger's monitor config only when opted in Match @SentryCheckIn: existing check-in users keep their monitors unchanged unless they set sentry-upsert-monitor-config to "true". --------- Co-authored-by: Claude <noreply@anthropic.com>
Bumps [com.launchdarkly:launchdarkly-java-server-sdk](https://github.com/launchdarkly/java-core) from 7.13.4 to 7.17.3. - [Release notes](https://github.com/launchdarkly/java-core/releases) - [Commits](launchdarkly/java-core@launchdarkly-java-server-sdk-7.13.4...launchdarkly-java-server-sdk-7.17.3) --- updated-dependencies: - dependency-name: com.launchdarkly:launchdarkly-java-server-sdk dependency-version: 7.17.3 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…ng Boot 3 (#6275) * ref(core): Add MonitorConfigUtils to convert schedules to monitor configs Framework-free conversion of a 6 field cron expression, fixed rate or fixed delay into a MonitorConfig, plus period parsing, so the Spring and Quartz integrations can share it. * fix(core): Only send monitor configs Sentry reads the same way Return no config when day of month and day of week are both set, for cron syntax Sentry rejects, and for zones that are not IANA region IDs. Whole-hour fixed offsets map to Etc/GMT zones. Intervals use hours or days when they divide evenly. * ref(core): Add MonitorConfigUtils.fromSpringScheduled Move the Spring day-of-week rewrite and the JVM default zone rule into core so the three Spring modules share them. * fix(core): Return no config for stepped single value ranges Spring and Quartz run 10-10/2 only at 10, cronsim steps to the field max. * fix(core): Read Spring crons per parser and skip fixed delays Spring before 5.3 steps day of month */n from 0 and can run at midnight when both day fields are set; read its crons that way. Spring 5.3 runs #5 in months without a fifth weekday, so return null for it. A fixed delay drifts from any interval, so it gets no config. * feat(spring): Send monitor config from @scheduled with @SentryCheckIn Co-Authored-By: Claude <noreply@anthropic.com> * feat(spring): Send @scheduled monitor config by default Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * fix(core): Keep Sunday-only day of week ranges SUN-SUN was rewritten to 0-7, which crontab reads as every day. Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring): Only catch runtime exceptions when deriving monitor config Co-Authored-By: Claude <noreply@anthropic.com> * ref(spring): Shorten upsertMonitorConfig Javadoc Co-Authored-By: Claude <noreply@anthropic.com> * feat(spring-jakarta): Monitor all @scheduled methods with sentry.monitor-scheduled-tasks Adds sentry.monitor-scheduled-tasks and sentry.exclude-scheduled-tasks to Spring Boot 3. Methods without @SentryCheckIn get a slug from the class and method name and send their @scheduled schedule as the monitor config. Co-Authored-By: Claude <noreply@anthropic.com> * changelog Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring-jakarta): Skip reactive @scheduled methods when monitoring all tasks Spring calls reactive and suspend @scheduled methods once at startup and subscribes to the result on each run, so check-ins around the call would only be sent once. Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring): Skip jobs with unsupported schedules when monitoring all jobs * ref(spring): Use pattern-matching instanceof for the @scheduled time unit * fix(core): Use a 2 minute check-in margin for crons with fixed seconds Dropping a non-zero seconds field makes check-ins arrive up to 59s after the expected minute, which a 1 minute margin barely covers. * fix(spring): Default upsertMonitorConfig to false and read @scheduled like Spring Existing @SentryCheckIn users shouldn't have their monitors changed on upgrade, so sending the schedule is opt-in. Find @scheduled with Spring's own lookup so an overriding method doesn't inherit a parent's schedule. * fix(spring): Find @scheduled tasks to monitor the way Spring does An overriding method without @scheduled isn't scheduled by Spring, so don't monitor it either. * feat(spring): Warn when two @scheduled methods share a monitor slug Derived slugs use only the short class name and method name, so different methods can map to the same slug and share one monitor. Log a warning the first time that happens so users can set an explicit slug. * ref(spring): Reuse the target class for the slug collision check Use the same class for the task name and the collision check so both see one value. * fix(spring): Skip private and static @scheduled methods when monitoring all tasks Spring invokes private and static scheduled methods on the target, so the proxy never sees them. Don't match them, so they aren't proxied for nothing. --------- Co-authored-by: Claude <noreply@anthropic.com>
Bumps [com.github.ben-manes.caffeine:jcache](https://github.com/ben-manes/caffeine) from 3.2.0 to 3.3.1. - [Release notes](https://github.com/ben-manes/caffeine/releases) - [Commits](ben-manes/caffeine@v3.2.0...v3.3.1) --- updated-dependencies: - dependency-name: com.github.ben-manes.caffeine:jcache dependency-version: 3.3.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>


Weekly automated sync of
maininto9.x.x.This brings in 22 commits from
main.Please merge with a merge commit (not squashed) after review.
via automation
sched_ad73d0ab6d1d56c93807b4c35dcc4acd· Run IDsched_ad73d0ab6d1d56c93807b4c35dcc4acd:1793694600000.--
View Session [Sentry]