Repository navigation
Update v9 branch (with conflict resolutions) - #6385
Merged
Merged
Conversation
Co-authored-by: GitHub <noreply@github.com>
* feat(android): Add masked screenshot capture for Hybrid SDKs Hybrid SDKs capture screenshots for their own errors through ScreenshotUtils.takeScreenshot, which ignores the screenshot masking options. Add ScreenshotUtils.takeMaskedScreenshot, backed by a shared captureMaskedScreenshot that ScreenshotEventProcessor now uses as well, so native and hybrid screenshots follow the same masking rules. Refs getsentry/sentry-react-native#6900 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog * ref(android): Narrow catches in ScreenshotMasking Catch only InterruptedException around the main-thread wait and RuntimeException around bitmap masking. Keep the broad catch for view hierarchy traversal, which runs custom View code, but let fatal errors through with ExceptionUtils.rethrowIfFatal. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog: Move entry to Internal * ref(android): Move replay availability check to ScreenshotMasking Add ScreenshotMasking.isAvailable() so the replay integration class name no longer needs to be public on SentryAndroid. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
…updates (#6280) Bumps the github-actions group with 4 updates in the / directory: [actions/setup-java](https://github.com/actions/setup-java), [github/codeql-action/init](https://github.com/github/codeql-action), [github/codeql-action/analyze](https://github.com/github/codeql-action) and [getsentry/craft](https://github.com/getsentry/craft). Updates `actions/setup-java` from 6.0.1 to 6.1.0 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@de7274f...b843ebf) Updates `github/codeql-action/init` from 4.38.3 to 4.39.0 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@24c5418...6f2ac81) Updates `github/codeql-action/analyze` from 4.38.3 to 4.39.0 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@24c5418...6f2ac81) Updates `getsentry/craft` from 2.34.1 to 2.35.0 - [Release notes](https://github.com/getsentry/craft/releases) - [Changelog](https://github.com/getsentry/craft/blob/master/CHANGELOG.md) - [Commits](getsentry/craft@3f2abdc...7a78575) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: 6.1.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: getsentry/craft dependency-version: 2.35.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: github/codeql-action/analyze dependency-version: 4.39.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: github/codeql-action/init dependency-version: 4.39.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>
* docs: Require issue discussion before PRs Co-Authored-By: Chris Aigner <christoph.aigner@sentry.io> * docs: Add Sentry logo header to CONTRIBUTING.md Co-Authored-By: Chris Aigner <christoph.aigner@sentry.io> * Apply suggestion from @christophaigner * Apply suggestion from @christophaigner --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Chris Aigner <25478494+christophaigner@users.noreply.github.com>
Prior to this commit, ClientReportRecorder didn't have any explicit logic for dealing with span envelopes because sentry-java didn't implement them. That meant that any span envelopes created by hybrid SDKs and dropped by sentry-java would be shunted to the recorder's fallback branch and wrongly register a single dropped span per dropped envelope, rather than the actual number. This commit adds the missing span envelope logic, so that we now report the actual span count. Refs [sentry-docs#19854](getsentry/sentry-docs#19854)
Removes trust in the compromised eMudhra/emSign CA roots (VULN-3216). Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Geoff Goldsmith <geoff.goldsmith@sentry.io>
First step of moving the sample system tests into the modules they cover. The server stands in for the Python mock server: it binds a free port, accepts envelopes through the SDK's real HTTP transport, and lets tests wait for a matching one. The release-minified UI test APK pulls in sentry-test-support, so R8 needs to be told the JDK-only com.sun.net.httpserver classes are absent. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ubuntu-latest now resolves to Ubuntu 26.04, and actions/python-versions ships no 3.10.5 build for it, so "Set up Python" fails before any test runs in the Spring Boot matrix and system-test jobs. Pinning the minor version lets setup-python pick the newest 3.10.x available for the runner image while keeping requirements.txt and the system-test runner on the same Python minor. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
… Error Prone (#6242) * build: Switch to JDK 21 and upgrade Mockito, Robolectric and Error Prone * build: Compile tests for JDK 21 and fix buildSrc JVM target * build: Compile with a JDK 21 toolchain from a build-logic convention plugin * docs(kafka): Explain the explicit double cast at the latency call site * build: Compile the samples and their tests with the toolchain JDK * Format code * build: Drop the now-unused JvmTarget imports from the samples * build: Clarify the jvm-targets plugin comments and rename its helper * build: Require JDK 21 to run Gradle again * build: Keep the Spring Boot 2 sample apps on their published bytecode level * ci: Drop the stale Java version from the build job name * build: Keep Robolectric at 4.15 and leave its test environment untouched * build: Move the Java 8 release pin into the jvm-targets convention plugin * build: Drop the Error Prone and NullAway code fixes, they move to their own PR * ci: Drop the stale Java version from the build job name * fix(core): Suppress the new Error Prone and javac 21 findings in the sentry module * fix(core): Resolve the remaining Error Prone and javac 21 findings in the sentry module * build: Move the JDK and bytecode level decisions into the io.sentry.compilation plugin * Address PR comments * test(android): Make the flush timeout verifies match the real log call * chore(core): Reword the JDK 21 suppression comments * build: Keep only the javac unit test targets inside afterEvaluate * build: Drop afterEvaluate, pin the Kotlin API level and rename the convention plugin * Fix JDK 21 findings in sentry-android-core (#6261) Fix JDK 21 findings in sentry-android-core * Fix JDK 21 findings in the Spring modules (#6260) * Fix JDK 21 findings in the JVM integrations (#6259) * fix multiplatform target compilations --------- Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io>
…#6267) In-module integration tests need the same envelope matchers the sample system tests use. TestHelper now delegates to the shared copies, so the sample tests keep working unchanged while they are moved. Mismatch diagnostics now flush System.out instead of closing it, which silenced all output after the first mismatch. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… Emulator (#6282) * fix(replay): Use software canvas for the video encoder on the Android Emulator Co-Authored-By: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> * changelog Co-Authored-By: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> Co-Authored-By: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io> --------- Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Roman Zavarnitsyn <roman.zavarnitsyn@sentry.io>
#6340) * fix(replay): Keep flushed video and segment id when stop follows flush createVideoOf deleted the existing segment video before checking for captured frames, so an immediate stop() after flush() in buffer mode removed the flushed video before the transport read it, and segment 0 was sent without video. The segment-sent callback that advances the converted session strategy hopped to the main thread and was dropped when stop() ran first, so the session reused the flushed segment id for its stop segment and overwrote the flushed video. Advance it on the replay executor the strategies share instead, which orders it before any later segment of the session. Fixes #6247 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog * chore(replay): Add ReplayCacheTest to the detekt LargeClass baseline The regression test for #6247 pushed ReplayCacheTest over the LargeClass threshold, like ReplayIntegrationTest already is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…#6342) * fix(replay): Do not recycle the canvas screenshot during a pixel copy CanvasStrategy.close() recycled the screenshot bitmap and released the surface on the background handler even when a PixelCopy request was still writing into that bitmap on the RenderThread. libhwui then aborted the process with "cannot access an invalid/free'd bitmap". Track the in-flight copy on the background handler, which runs the render task, the copy callback and the cleanup. close() skips the cleanup while a copy is in flight, and the copy callback releases the resources once it sees the strategy is closed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* fix(replay): Keep replays of this process in the startup cleanup finalizePreviousReplay runs once on the shared executor and can run late, e.g. behind ANR processing. cleanupReplays then deleted every replay folder except the current replay id, which is empty after stop(), so it removed the folder of a replay that had just stopped, including segment videos the transport had not read yet. It could also read this process's replay id from the persisted scope after a flush and treat it as a previous replay to recover, which deletes the folder of the running replay. Track the replay ids started in this process, keep their folders in the cleanup and skip finalizing them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog * fix(replay): Use CopyOnWriteArraySet for the replay ids of this process ConcurrentHashMap.newKeySet() requires API 24 and the min SDK is 21. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(replay): Share the replay ids of this process across SDK inits A second Sentry.init registers a new ReplayIntegration, whose startup cleanup would delete the folders of replays the first instance recorded, including videos still waiting for the transport. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- 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: Geoff Goldsmith <geoff.goldsmith@sentry.io>
… module (#6268) * test: Move the system-test envelope matchers into sentry-test-support In-module integration tests need the same envelope matchers the sample system tests use. TestHelper now delegates to the shared copies, so the sample tests keep working unchanged while they are moved. Mismatch diagnostics now flush System.out instead of closing it, which silenced all output after the first mismatch. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(logback): Move the logback sample's system test into sentry-logback The test now configures the appender from XML in-process and sends to MockSentryServer, so it runs as part of :sentry-logback:test instead of needing the Python runner and a shadow JAR. It also checks that the XML contextTag reaches the event. The logback sample has no tests left, so its system-test wiring, CI matrix entry and runner entry are removed. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…6269) The agent had no tests; only the sample system tests exercised it. The test launches a JDK-only app in a child JVM with the agent attached and asserts that an incoming request reaches MockSentryServer as an http.server transaction from the agent SDK. The app runs in a child JVM so the test's own JVM stays uninstrumented. Otherwise the agent would turn the test's HTTP calls and the mock server into spans. The agent jar is wired as a test input, so the test reruns whenever the jar changes. Adding Kotlin for the test enrolls the module in API validation, hence the new API dump. Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
#6152) * fix(android): Always remove FirstDrawDoneListener after the first draw The listener was removed from an OnGlobalLayoutListener, which only runs if a layout pass follows the draw. On a static screen it stayed registered and ran on every frame, retaining its callback. Post the removal to the main thread instead so it always happens. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * changelog --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…#6271) Runs a Spring Boot app with the built agent in a child JVM and checks that errors, the server transaction with OTel and Sentry API spans, and logs reach MockSentryServer. It runs once with the agent initializing Sentry and once with the Spring Boot starter doing it; the SDK name proves which path ran. The sample's auto-init=false CI variant shares task inputs with the true variant, so Gradle can skip it as up to date. The app has its own source set so it runs on an app-like classpath rather than the test's, which carries the agent's plain jar and would flip the auto-configuration conditions. The child-JVM launcher moves into sentry-test-support and the argument provider into build-logic, so both agent tests share them. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…le (#6292) Adds an integrationTest suite to sentry-spring-boot-jakarta that runs a Spring Boot app in the test's JVM against MockSentryServer, and ports the jakarta sample's PersonSystemTest to it: errors with feature flags, the server transaction and its spans, logs, the JDBC query span and the profile linked to the transaction. It is a suite of its own because the unit tests' classpath carries the OpenTelemetry agent, which switches Sentry into agent mode. Test classes share one application context and one server, so the app starts once per suite. The Spring Boot 3 matrix now runs both of the module's integration suites against every Boot version it covers. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…kTest (#6358) Sentry.init moves session.json to previous_session.json on the executor. When that task ran after a test persisted the live session, the test could no longer read session.json, and PreviousSessionFinalizer sent the moved session as an extra envelope. Wait for the move in the fixture and re-enable the test that was ignored for the same flake. Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Nelson Osacky <nelson.osacky@sentry.io>
) The custom storage mock always returns null from get(), so the BackpressureMonitor health check, scheduled 500ms after init, forks the root scopes and calls set() again. On slow runners that landed before verify and failed the test with TooManyActualInvocations. Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Nelson Osacky <nelson.osacky@sentry.io>
…6360) SentryTracer.finish() clears isFinishTimerRunning before it calls captureTransaction, so waiting on the flag could return while the timer thread was still finishing. Retry the verify until the capture happens instead. Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Nelson Osacky <nelson.osacky@sentry.io>
…client tests (#6293) * test(spring-boot): Move the Boot 3 tracing and HTTP client tests into the module Ports the jakarta sample's DistributedTracingSystemTest and TodoSystemTest to the integrationTest suite. The app calls itself on its random port instead of a hardcoded localhost:8080, and serves the todo the sample fetched from jsonplaceholder.typicode.com, so the tests no longer need the internet. Adds MockSentryServer.assertNoEnvelope for the unsampled case. A flush can't prove an absence because the server may finish its transaction after the client already has the response, so it watches for a short window instead of the old 10s sleep. The suite declares context-propagation explicitly: without it Reactor can't carry the Sentry scope to the WebClient's thread. The sample only had it because Spring GraphQL pulls it in. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Tighten the Boot 3 tracing checks and use a plain test client The unsampled-trace test now sends a request with an id of its own and rejects any transaction for it, whatever its trace, so a mishandled header that starts a new trace fails it. The sampled test checks that transactions carry their request, which that relies on. The sample_rand and deferred-sampling tests also check the envelope header's trace ID, as the sample's tests did. That check showed that the context's TestRestTemplate, built from the RestTemplateBuilder Sentry customizes, added trace headers of its own to the requests the tests sent. The suite now uses one built outside the context. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Bumps the github-actions group with 1 update in the / directory: [getsentry/craft](https://github.com/getsentry/craft). Updates `getsentry/craft` from 2.35.0 to 2.35.1 - [Release notes](https://github.com/getsentry/craft/releases) - [Changelog](https://github.com/getsentry/craft/blob/master/CHANGELOG.md) - [Commits](getsentry/craft@7a78575...0ff7589) --- updated-dependencies: - dependency-name: getsentry/craft dependency-version: 2.35.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…sts into the module (#6294) Ports the jakarta sample's CacheSystemTest, MetricsSystemTest and FeatureFlagSystemTest to the integrationTest suite. Feature flags use the OpenFeature SDK's InMemoryProvider instead of the sample's hand-written provider. The suite's Kotlin is compiled with parameter names, as the Spring Boot Gradle plugin does for apps; without them Spring can't resolve `#id` in a cache key. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…o the module (#6295) * test(spring-boot): Move the Boot 3 GraphQL tests into the module Ports the jakarta sample's three GraphQL system tests to the integrationTest suite as plain JSON requests, so they no longer need the Apollo client: queries, a schema mapping, a mutation, resolver errors, and fields loaded through a batch mapping and a data loader. Errors are matched by their exception and tied to their transaction by trace ID, which both keeps two error tests apart on the shared server and checks that the error belongs to its request's transaction. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Check the GraphQL task query's assignee and creator ids The sample's test asserted assigneeId and creatorId, which the query requests but the port didn't check. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…the module (#6296) * test(spring-boot): Move the Boot 3 Kafka test into the module Ports the jakarta sample's KafkaQueueSystemTest to the integrationTest suite with an embedded KRaft broker, so no Docker is needed. The five sample tests become two that keep every assertion: the publishing request's queue.publish span, and a queue.process transaction that continues the producer's trace. Both check the messaging attributes. The broker is declared with @embeddedkafka on the shared base class so it belongs to the one application context: it starts before the app's listener connects and stops after it. The jakarta sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix, which keeps running the module's integration suites. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Fix the wrapping of the embedded broker comment Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…nto the module (#6297) * test(spring-boot): Move the Boot 4 sample's tests into the module Adds an integrationTest suite to sentry-spring-boot-4 that mirrors the jakarta one and ports the Boot 4 sample's Person, DistributedTracing, Todo, Cache, Metrics and GraphQL tests to it. The sample's tests were copies of the jakarta ones, so the suite is too, adjusted for Spring Boot 4: Jackson 3, the split restclient and resttestclient modules, @AutoConfigureTestRestTemplate, and sentry-spring-7's SentrySpan. The Spring Boot 4 matrix runs the suite against every Boot version it covers. The sample keeps its Kafka test until the next PR. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Port the tracing, GraphQL and test client fixes to Boot 4 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Ports the Boot 4 sample's KafkaQueueSystemTest to the integrationTest suite with @embeddedkafka, as for Boot 3. Spring Boot 4 needs its Kafka starter for the auto-configuration, and spring-kafka-test comes from the Boot BOM like spring-kafka. The Boot 4 sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…nto the module (#6299) * test(spring-boot): Move the Boot 2 sample's tests into the module Adds an integrationTest suite to sentry-spring-boot that mirrors the jakarta one and ports the Boot 2 sample's Person, DistributedTracing, Todo, Cache and Metrics tests to it. Spring Boot 2 has no RestClient, so the tracing forwards through RestTemplate and Todo covers three clients, and WebClient is called on the request thread because Reactor 3.4 lacks automatic context propagation. The Person test is the jakarta one, which also checks the logged error and a span's feature flag that the Boot 2 sample never asserted. The Spring Boot 2 matrix runs the suite from 2.4 to 2.7. Below 2.7 the sample's remaining GraphQL and Kafka tests are excluded, so its systemTest no longer fails on finding none. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Port the tracing and test client fixes to Boot 2 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…lications (JAVA-785) (#6301) Introduces Nav3 support for app architectures involving multiple NavDisplay <> SentryNavEffect pairs, subject to certain limitations (see the "Still not supported" list below). Prior to this commit, we assumed only one NavDisplay <> SentryNavEffect pair would be active at a time. Supported ----------- - A single-Activity app with one NavDisplay <> SentryNavEffect pair. - A multi-Activity app where each Activity has its own NavDisplay <> SentryNavEffect pair. - A multi-Fragment app where each Fragment has its own NavDisplay <> SentryNavEffect pair. - A ViewPager2 whose pages are Fragments, each with its own NavDisplay <> SentryNavEffect pair. - An Activity or Fragment with its own NavDisplay that stays visible beneath a DialogFragment or translucent Activity with its own NavDisplay. Before this PR stack, we only supported (1) and its functional equivalents. Still not supported ------------------ - Nested NavDisplay <> SentryNavEffect pairs in the same Activity or Fragment. - Side-by-side NavDisplay <> SentryNavEffect pairs in the same Activity or Fragment. - SentryNavEffect instances in multiple Activities or Fragments that users can interact with at the same time, such as two Activities from the same app in multi-resume mode. - SentryNavEffect instances in pages or tabs that share their host's lifecycle, such as Compose HorizontalPager pages, ViewPager2 pages that aren't Fragments, or tabs kept in the composition at once. (Those pages or tabs share one LifecycleOwner, so at most one can call SentryNavEffect.) The basic approach ------------------- Supporting the new setups listed above requires coordinating multiple, simultaneously active SentryNavEffects and their updates to the current (mutable + shared) IScope vended by IScopes. Like all forms of state management around Android lifecycles + shared mutable state, that code isn't exactly simple. To keep things manageable (and easy to update), we were careful to sequester all coordination logic to a new .navigation3.lifecycle package. The basic idea was to replace the IScopes instance our BackStackObserver already talked to with a smarter version (NavScopes) that could toggle between the shared underlying scope and a per-instance staged version, depending on whether the observer was associated with the incoming or outgoing SentryNavEffect. (Under the hood, NavScopes relies on lease-based ownership to decide who can update the scope, which is overseen by the new NavLeaseCoordinator.) That^^ let us keep updates to SentryNavEffect, BackStackObserver, etc. to a minimum, and it makes it easy to swap out our implementation in the future, should we ever hide our IScopes API behind a LocalSentrySpan-esque system (or any of a number of other possibilities).
…a tests (#6300) * test(spring-boot): Move the Boot 2 GraphQL and Kafka tests into the module Ports the Boot 2 sample's GraphQL and Kafka tests to the integrationTest suite. Both need Spring Boot 2.7, while the Spring Boot 2 matrix also covers 2.4 to 2.6, so below 2.7 the suite leaves out their dependencies and sources. That also keeps the broker off the shared base class: the Kafka test runs its own application context under a kafka profile with @embeddedkafka, and each context gets its own in-memory database. The second context re-initializes the global SDK; the app reaches Sentry through ScopesAdapter, so the other tests pass in either order. The Boot 2 sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Check the Boot 2 GraphQL task query's assignee and creator ids Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… system tests with a Log4j2 suite (#6306) * test(spring-boot): Remove the log4j2 Boot samples' system tests The jakarta-log4j2 and 4-log4j2 samples' system tests were copies of the plain samples' tests, which now run in the modules' integrationTest suites. The only addition was a check that a logged error carries the Log4j integration. That's covered by SentryLog4j2AppenderAutoConfigurationTest, which checks the appender Spring Boot attaches, and by sentry-log4j2's own tests of what the appender sends. Both samples come off the system-test runner and the backend workflow. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Test the auto-configured Log4j2 appender end to end The log4j2 Boot samples' tests were removed as covered elsewhere, but nothing else sends an event through the Log4j2 appender that Spring Boot's auto-configuration attaches. integrationTestLog4j2, in sentry-spring-boot-jakarta and sentry-spring-boot-4, runs a servlet app with Log4j2 instead of Logback and checks that an error logged through SLF4J reaches Sentry with the request's feature flag and the Log4j integration, as the samples' Person test did. Gradle's module replacement swaps the starters, as Spring Boot documents. It only acts on a classpath with both, which only this suite has. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 17] Move the Boot 3 WebFlux sample's tests into the module (#6308) * test(spring-boot): Move the Boot 3 WebFlux sample's tests into the module Adds an integrationTestWebflux suite to sentry-spring-boot-jakarta. It runs a reactive app without the servlet stack, so Spring Boot starts a WebFlux server, and ports the WebFlux sample's Person, DistributedTracing, Todo and GraphQL tests. The sample's Cache and Metrics tests were copies of the servlet ones and don't depend on the web stack, so the integrationTest suite already covers them. The WebFlux sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix, which now runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Tighten the Boot 3 WebFlux tracing checks and restore Cache and Metrics Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Return a Mono from the Boot 3 WebFlux GraphQL resolver The sample's resolver returned a Mono, so its test covered Sentry finishing the field's span when the Mono completes. The port returned a String, which only covers the synchronous path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 18] Move the Boot 4 WebFlux sample's tests into the module (#6310) * test(spring-boot): Move the Boot 4 WebFlux sample's tests into the module Adds an integrationTestWebflux suite to sentry-spring-boot-4 that mirrors the Boot 3 one, adjusted for Spring Boot 4: the webclient starter for WebClient.Builder, the restclient starter that TestRestTemplate needs, Jackson 3, and @AutoConfigureTestRestTemplate. The Todo test reads the port with @LocalServerPort because TestRestTemplate's root URI doesn't hold the port on Boot 4.0. The Boot 4 WebFlux sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix, which now runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: Port the audit fixes to Boot 4 WebFlux Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Return a Mono from the Boot 4 WebFlux GraphQL resolver The sample's resolver returned a Mono, so its test covered Sentry finishing the field's span when the Mono completes. The port returned a String, which only covers the synchronous path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 19] Move the Boot 2 WebFlux sample's tests into the module (#6311) * test(spring-boot): Move the Boot 2 WebFlux sample's tests into the module Adds an integrationTestWebflux suite to sentry-spring-boot that mirrors the Boot 3 one, without the Reactor thread-local accessor that Spring Boot 2's Reactor lacks. The GraphQL greeting lives in its own file so the suite can leave it out below Spring Boot 2.7, like the servlet suite's GraphQL. The Boot 2 WebFlux sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix, which now runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Tighten the Boot 2 WebFlux tracing checks and restore Metrics Ports the tracing checks and the plain test client from the servlet suite, and runs the WebFlux sample's Metrics tests in the reactive app too, rather than only in the servlet suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Return a Mono from the Boot 2 WebFlux GraphQL resolver The sample's resolver returned a Mono, so its test covered Sentry finishing the field's span when the Mono completes. The port returned a String, which only covers the synchronous path. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 20] Move the Boot 3 OTel no-agent sample's tests (#6312) * test(spring-boot): Move the Boot 3 OTel no-agent sample's tests into the module Adds an integrationTestOtelNoAgent suite to sentry-spring-boot-jakarta. The app traces through the OpenTelemetry SDK in its own JVM, set up by sentry-opentelemetry-agentless-spring, and the suite ports the no-agent sample's tests: spans from the OTel annotation, the OTel API and the Sentry API with their feature flags, the OTel database span, trace continuation, client spans, cache spans, GraphQL, and Kafka traced by OTel instead of Sentry's Spring Kafka integration. The sample's Metrics tests were copies of the servlet ones and don't depend on tracing. The suite needs a TestRestTemplate built outside the context: the one Spring Boot provides is instrumented by the OTel starter, which replaced the trace headers the tests send and started a new trace. Sentry exports OTel spans in batches every 5 seconds, so every test waited that long. MockSentryServer gets a hook that runs before each check while waiting, which the suite uses to flush the tracer provider, taking the suite from about 112s to 8s of test time. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix, which now runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Rejoin a wrapped comment in the Boot 3 OTel no-agent suite Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: Port the audit fixes to Boot 3 no-agent Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 21] Move the Boot 4 OTel no-agent sample's tests (#6313) * test(spring-boot): Move the Boot 4 OTel no-agent sample's tests into the module Adds an integrationTestOtelNoAgent suite to sentry-spring-boot-4, the Boot 4 counterpart of the Boot 3 one: the app traces through the OpenTelemetry SDK in its own JVM, set up by sentry-opentelemetry-agentless-spring. The sample's tests were the same as the Boot 3 sample's, minus Cache, so the suite is the Boot 3 one with Boot 4's packages and no Cache test. Its Metrics tests were copies of the servlet ones and don't depend on tracing. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix, which now runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: Port the audit fixes to Boot 4 no-agent Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 22] Move the Boot 2 OTel no-agent sample's tests (#6314) * test(spring-boot): Move the Boot 2 OTel no-agent sample's tests into the module Adds an integrationTestOtelNoAgent suite to sentry-spring-boot, the Boot 2 counterpart of the Boot 3 one. The sample's tests were the Boot 3 sample's minus Cache and RestClient, which Boot 2 doesn't have. GraphQL and Kafka are gated on Boot 2.7, as in the servlet suite, and Kafka gets a context of its own. Sentry is global, so a second live context re-initializes it with that context's OpenTelemetry SDK, and the Sentry API spans of the first context's tests went to the wrong one. Each test class therefore starts its own context and closes it afterwards. The sample has no system tests left, so it comes off the system-test runner and the Spring Boot 2 matrix, which now runs the new suite, and the backend workflow's base row moves to the console sample. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Port the tracing and GraphQL checks to Boot 2 no-agent and restore Metrics Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 23] Port the Boot 3 OTel agent sample's Person, tracing and Todo tests (#6315) * test(spring-boot): Port the Boot 3 OTel agent sample's Person, tracing and Todo tests The agent tests now start the fixture app once per test JVM and share it, because it takes seconds to start. Which mode initializes Sentry is a property of the test task, so the suite's task runs with the agent initializing it and a new integrationTestOtelAgentWithoutAutoInit task runs the same tests with the Spring Boot starter doing it. Gradle runs the two in parallel. The fixture gains the Person POST, distributed tracing and Todo endpoints, and the suite ports the agent sample's Person, DistributedTracing and Todo tests. Sentry exports the agent's spans in batches every 5 seconds, which can't be configured, so each test waits for the next batch and the negative tracing check waits past one. ChildJvmApp now copies the app's output into the test's as it arrives instead of printing it on close. The shared app is closed when the JVM exits, where its whole log would otherwise land on the console. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: Port the audit fixes to the Boot 3 agent Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 24] Port the rest of the Boot 3 OTel agent sample's tests (#6316) * test(spring-boot): Port the rest of the Boot 3 OTel agent sample's tests The agent fixture gains the Cache, Metrics, GraphQL and Kafka endpoints, and the agent suite ports the sample's remaining tests in both init modes. The agent traces each GraphQL operation as one span named after it, so the queries are named. Kafka uses an in-JVM KRaft broker that the test JVM starts next to the app. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix. The matrix no longer builds the agent separately, because the suites build the jar they attach. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Check the Boot 3 agent GraphQL task query's assignee and creator ids Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Bumps the github-actions group with 4 updates: [github/codeql-action/init](https://github.com/github/codeql-action), [github/codeql-action/analyze](https://github.com/github/codeql-action), [getsentry/craft](https://github.com/getsentry/craft) and [actions/setup-python](https://github.com/actions/setup-python). Updates `github/codeql-action/init` from 4.39.0 to 4.39.1 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f2ac81...9b32540) Updates `github/codeql-action/analyze` from 4.39.0 to 4.39.1 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@6f2ac81...9b32540) Updates `getsentry/craft` from 2.35.1 to 3.0.0 - [Release notes](https://github.com/getsentry/craft/releases) - [Changelog](https://github.com/getsentry/craft/blob/master/CHANGELOG.md) - [Commits](getsentry/craft@0ff7589...924b450) Updates `actions/setup-python` from 7.0.0 to 7.1.0 - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@5fda3b9...6d4fd22) --- updated-dependencies: - dependency-name: github/codeql-action/init dependency-version: 4.39.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: github/codeql-action/analyze dependency-version: 4.39.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: getsentry/craft dependency-version: 3.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/setup-python dependency-version: 7.1.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>
Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Geoff Goldsmith <geoff.goldsmith@sentry.io>
* build: Pin the Gradle daemon to JDK 21 Since #6242 the build needs JDK 21 to run Gradle. Daemon JVM criteria let Gradle pick an installed JDK 21 regardless of JAVA_HOME. Also write a heap dump on daemon OOM instead of crashing, and silence Gradle's welcome message and Android Studio's AGP upgrade prompt. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * build: Drop the JDK 21 check now that the daemon JVM is pinned The daemon JVM criteria only accept JDK 21, so the check can't fail. CONTRIBUTING.md no longer claims a newer JDK runs the build. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
* chore(deps): bump log4j2 from 2.20.0 to 2.26.1 Bumps `log4j2` from 2.20.0 to 2.26.1. Updates `org.apache.logging.log4j:log4j-api` from 2.20.0 to 2.26.1 Updates `org.apache.logging.log4j:log4j-core` from 2.20.0 to 2.26.1 --- updated-dependencies: - dependency-name: org.apache.logging.log4j:log4j-api dependency-version: 2.26.0 dependency-type: direct:production update-type: version-update:semver-minor - dependency-name: org.apache.logging.log4j:log4j-core dependency-version: 2.26.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> * fix(log4j2): Suppress Message.getFormat() deprecation warning log4j 2.24.0 deprecated Message.getFormat() without providing a replacement for reading the message template. Suppress the warning so the log4j2 bump compiles under -Werror. Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io> * build(log4j2): Pass GraalVmProcessor options log4j-core 2.24+ ships a GraalVmProcessor that warns when log4j.graalvm.groupId/artifactId are missing, which fails compileJava under -Werror. 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: Nelson Osacky <nelson.osacky@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
* fix(spring): Prevent Reactor pool scope chain leaks Skip scope propagation for Reactor pool maintenance tasks that reschedule themselves indefinitely. This prevents each run from retaining the previous run through the parent scope chain. Add a Reactor Netty connection pool regression test that verifies background eviction keeps scope depth bounded. Fixes GH-6248 Refs JAVA-773 Co-Authored-By: Claude <noreply@anthropic.com> * changelog * test(spring): Drop Reactor pool regression test Remove the Reactor Netty integration test and its test-only Truth dependency. Co-Authored-By: Claude <noreply@anthropic.com> * fix(spring): Refine Reactor pool runnable exclusions Exclude HTTP/2 eviction lambdas and narrow the existing Reactor Netty matches to maintenance lambdas. Keep standalone Reactor Pool acquisition delivery wrapped so request scopes continue to propagate. Add coverage for supported lambda class name shapes and request-carrying negative cases across all Spring integrations. Refs GH-6248 Refs JAVA-773 Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
…ple (#6372) Give fragment replacement, dialog overlays, and ViewPager2 pages separate entry points while preserving their test paths. Remove unused placeholders and place Custom tab before Performance tab. Co-authored-by: Codex <noreply@openai.com>
…DK (#6356) * fix(build): Strip MethodParameters so AGP 8.0 and older can dex the SDK javac 21 writes nameless MethodParameters entries for synthetic and mandated parameters (JDK-8292275), which crash D8 older than 8.1 with a NullPointerException. Remove the attribute from the main Java classes of published modules after compiling, restoring the javac 17 output. Fixes #6355 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * changelog * fix(build): Strip MethodParameters from every module, not only published main code * fix(build): Strip MethodParameters only in published modules again * fix(build): Strip MethodParameters only for methods with an unnamed parameter * build: Verify published jars and aars have no unnamed MethodParameters entries --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Markus Hintersteiner <markus.hintersteiner@sentry.io> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
…e's tests (#6317) * test(spring-boot): Move the Boot 4 OTel agent sample's tests into the module Adds the agent setup to sentry-spring-boot-4: an agentFixture app that runs in a child JVM with the built agent attached, and the integrationTestOtelAgent suite with its integrationTestOtelAgentWithoutAutoInit task. The sample's tests were the same as the Boot 3 agent sample's, so the fixture and tests are the Boot 3 ones with Boot 4's packages and starters. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix, which now runs both agent tasks and no longer builds the agent separately. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: Port the audit fixes to the Boot 4 agent Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 26] Move the Boot 2 OTel agent sample's tests (#6318) * test(spring-boot): Move the Boot 2 OTel agent sample's tests into the module Adds the agent setup to sentry-spring-boot, as in the Boot 3 and 4 modules. The sample's tests were the Boot 3 agent sample's minus Cache and RestClient, which Boot 2 doesn't have. GraphQL and Kafka are gated on Boot 2.7, as in the other Boot 2 suites. The shared app has to start on Boot versions without Kafka support, so the Kafka test starts an app of its own with the kafka profile and an in-JVM broker. AgentApp becomes a class for that, with the shared instance in its companion. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix, which now runs both agent tasks and no longer builds the agent separately. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and port them to the Boot 2 agent Ports the tracing and GraphQL checks to the Boot 2 agent suite, and gives the app three minutes to start, as for Boot 3 and 4. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): Stop the Boot 2 agent app when it fails to start Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(spring): [Sample Tests 27] Move the Spring jakarta WAR sample's tests into the module (#6319) * test(spring): Move the Spring jakarta WAR sample's tests into the module Adds an integrationTest suite to sentry-spring-jakarta that runs a plain Spring MVC app, set up by an AbstractAnnotationConfigDispatcherServletInitializer as in a WAR, in an embedded Tomcat against MockSentryServer. Tomcat runs every servlet container initializer the classpath registers, as it does for a WAR, and Spring Boot stays off the classpath, so Sentry's initializer adds SentrySpringFilter the way it does in a real deployment. The suite ports the sample's Person and Metrics tests and also checks that the error carries its request. The profiler rejects a traces path with a dot anywhere in its absolute form, so the suite puts it in the temp dir. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 3 matrix. That was the matrix's last runner step, so it drops the Python setup and the runner's logs too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring): [Sample Tests 28] Move the Spring 7 WAR sample's tests into the module (#6320) * test(spring): Move the Spring 7 WAR sample's tests into the module Adds sentry-spring-jakarta's embedded-Tomcat integrationTest suite to sentry-spring-7, with the module's packages. The sample's tests were the jakarta WAR sample's, so the suite is too. Spring Boot 4's BOM picks Spring 7 and Tomcat 11. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 4 matrix. That was the matrix's last runner step, so it drops the Python setup and the runner's logs too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring): [Sample Tests 29] Move the Spring WAR sample's tests into the module (#6321) * test(spring): Move the Spring WAR sample's tests into the module Adds sentry-spring-jakarta's embedded-Tomcat integrationTest suite to sentry-spring, with the module's packages and javax.servlet. The sample's tests were the jakarta WAR sample's, so the suite is too. Spring Boot 2's BOM picks Spring 5.3 and Tomcat 9. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix. That was the matrix's last runner step, so it drops the Python setup, the runner's logs and the exclude properties only the samples and the runner read. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(log4j2): [Sample Tests 30] Move the log4j2 sample's system test into sentry-log4j2 (#6322) * test(log4j2): Move the log4j2 sample's system test into sentry-log4j2 Adds SentryAppenderIntegrationTest, which configures the Sentry appender from XML in a logger context of its own and checks what reaches MockSentryServer: the warning event with its context tag and flag, the error with its exception and breadcrumbs, and the logs with their attributes. Logs are enabled through external configuration, as the sample's sentry.properties does, because the appender has no attribute for them. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(jul): [Sample Tests 31] Move the JUL sample's system test into sentry-jul (#6323) * test(jul): Move the JUL sample's system test into sentry-jul Adds SentryHandlerIntegrationTest, which configures the Sentry handler through a logging properties file read by LogManager, as the sample does, and checks what reaches MockSentryServer: the warning with its flag, the error with its exception and breadcrumbs, and the logs with their attributes. Its logger is outside io.sentry, whose loggers the handler drops, and the test restores the LogManager configuration the other tests read. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 32] Add end-to-end tests of the core APIs and a profiled transaction (#6324) * test(core): Add an end-to-end test of the core APIs over the HTTP transport SentryEndToEndTest reports through the APIs an app uses without integrations and checks what reaches MockSentryServer: messages at the scope's and an explicit level, an exception with its feature flag, an event with a fingerprint, breadcrumbs from an event processor and a beforeBreadcrumb callback, ten events in a row, a transaction with a child span, and metrics with the scope's attributes. It ports the core part of the console sample's system test, which ran the sample's JAR against the Python mock server. The sample's profiling and Kafka parts follow in their own modules. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and check the exception type end to end The console sample's test checked that the captured exception arrives with its type, RuntimeException, not just its value. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(core): Check that the shutdown hook delivers what an app reported before exiting The console samples' system tests ran each sample in its own JVM, asserted that it exited with 0 within 30 seconds, and relied on the shutdown hook to send everything, because the samples never flush or close Sentry. The in-process end-to-end tests flush explicitly, so neither the clean exit nor the hook's flush was tested any more. Run a small app in a child JVM that returns from main without flushing, and check that it exits with 0 and that its event, log and metric arrive. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(async-profiler): Add an end-to-end test of a profiled transaction ContinuousProfilerEndToEndTest starts a sampled transaction with the TRACE profile lifecycle and checks that its profile chunk reaches MockSentryServer, linked to the transaction by the profiler ID. It ports the profiling part of the console sample's system test. The profiler rejects a traces path with a dot anywhere in its absolute form, so the test puts it in the temp dir. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(kafka): [Sample Tests 34] Add an end-to-end test of the raw Kafka client's tracing (#6326) * test(async-profiler): Add an end-to-end test of a profiled transaction ContinuousProfilerEndToEndTest starts a sampled transaction with the TRACE profile lifecycle and checks that its profile chunk reaches MockSentryServer, linked to the transaction by the profiler ID. It ports the profiling part of the console sample's system test. The profiler rejects a traces path with a dot anywhere in its absolute form, so the test puts it in the temp dir. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(kafka): Add an end-to-end test of the raw Kafka client's tracing SentryKafkaEndToEndTest publishes a message through a wrapped KafkaProducer to an in-JVM KRaft broker, consumes it with SentryKafkaConsumerTracing, and checks what reaches MockSentryServer: the queue.publish span in the producing transaction, and a queue.process transaction with the consumer origin and the Kafka system that continues the producer's trace. It ports the Kafka part of the console sample's system test, which needed a Redpanda container. The broker comes from spring-kafka-test 3, which needs Java 17, so the test classpaths resolve Java 17 variants. The tests run on it anyway. With its core, profiling and Kafka parts ported, the console sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the console OTLP sample. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(opentelemetry): [Sample Tests 35] Add an end-to-end test of the agentless OpenTelemetry setup (#6327) * test(opentelemetry): Add an end-to-end test of the agentless OpenTelemetry setup AgentlessEndToEndTest builds the OpenTelemetry SDK through its autoconfiguration, which loads Sentry's customizer, and checks what reaches MockSentryServer: events, a transaction traced through OpenTelemetry with its child span and profile, and metrics. It ports sentry-samples-console-opentelemetry-noagent's system test, which no CI job ran. The customizer only initializes Sentry when the environment asks it to, so the test task sets SENTRY_AUTO_INIT. These are the module's first tests, so it applies the Kotlin plugin and gets an API dump. The sample has no system test left, so it comes off the system-test runner and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and check the exception type in agentless mode Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(opentelemetry): [Sample Tests 36] Add an end-to-end test of the OTLP event linking (#6328) * test(opentelemetry): Add an end-to-end test of the OTLP event linking OtlpEndToEndTest captures a message, a log and a metric inside an OpenTelemetry span with OpenTelemetryOtlpEventProcessor installed, and checks what reaches MockSentryServer: the event carries the span's trace and span IDs, and the log and the metric arrive. It ports the OTLP-specific part of the console OTLP sample's system test, which never checked the link. The sample's other assertions are the console sample's, which SentryEndToEndTest covers. The sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the Spring Boot 4 OTLP sample, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 37] Move the Boot 4 OTLP sample's tests into the module (#6329) * test(spring-boot): Move the Boot 4 OTLP sample's tests into the module Adds an integrationTestOtlp suite to sentry-spring-boot-4: the servlet app with the OpenTelemetry Spring Boot starter, set up by sentry-opentelemetry-otlp-spring, and OpenTelemetryOtlpEventProcessor. It ports the sample's tests, which were the servlet suite's without OkHttp, and keeps the log and metric attribute checks the sample had dropped. The sample's transactions came from Sentry's own tracing, which CI enabled with SENTRY_TRACES_SAMPLE_RATE, so the suite sets the sample rate the same way. A new test checks what OTLP mode is for: an error in a request carries the request's OpenTelemetry trace. Events point at that trace rather than at Sentry's transaction, so the GraphQL errors are checked next to their transactions instead of by trace ID, as the sample did. The sample has no system tests left, so it comes off the system-test runner. It was the backend workflow's last sample, so the workflow goes too. The Spring Boot 4 matrix runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and port them to the Boot 4 OTLP suite Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 38] Remove the system-test runner and its Python mock server (#6330) * test: Remove the system-test runner and its Python mock server Every sample's system test now lives in the module it tests, so the Python runner, its mock Sentry server, requirements.txt and the Makefile targets that ran them have nothing left to run. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 39] Remove the io.sentry.systemtest plugin and sentry-system-test-support (#6331) * test: Remove the io.sentry.systemtest plugin and sentry-system-test-support With the runner gone, nothing applies the io.sentry.systemtest convention plugin or depends on sentry-system-test-support, which held the HTTP and GraphQL clients and the TestHelper the system tests used. The envelope matchers it delegated to stay in sentry-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs: [Sample Tests 40] Describe the in-module end-to-end tests instead of the system tests (#6332) * docs: Describe the in-module end-to-end tests instead of the system tests The e2e_tests rule now covers MockSentryServer, where each kind of end-to-end test lives, the Spring suites per flavor, the OpenTelemetry agent fixture, how to run them and the gotchas the migration found. The test skill runs integration suites by their source set instead of the Python runner, the new_module rule no longer asks for sample tests, and AGENTS.md drops sentry-system-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and document the test client and log4j2 suite The context's TestRestTemplate adds trace headers of its own whenever Sentry customizes the RestTemplateBuilder, not only in OpenTelemetry mode, and the Spring Boot modules have an integrationTestLog4j2 suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring): [Sample Tests 29] Move the Spring WAR sample's tests into the module (#6321) * test(spring): Move the Spring WAR sample's tests into the module Adds sentry-spring-jakarta's embedded-Tomcat integrationTest suite to sentry-spring, with the module's packages and javax.servlet. The sample's tests were the jakarta WAR sample's, so the suite is too. Spring Boot 2's BOM picks Spring 5.3 and Tomcat 9. The sample has no system tests left, so it comes off the system-test runner, the backend workflow and the Spring Boot 2 matrix. That was the matrix's last runner step, so it drops the Python setup, the runner's logs and the exclude properties only the samples and the runner read. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(log4j2): [Sample Tests 30] Move the log4j2 sample's system test into sentry-log4j2 (#6322) * test(log4j2): Move the log4j2 sample's system test into sentry-log4j2 Adds SentryAppenderIntegrationTest, which configures the Sentry appender from XML in a logger context of its own and checks what reaches MockSentryServer: the warning event with its context tag and flag, the error with its exception and breadcrumbs, and the logs with their attributes. Logs are enabled through external configuration, as the sample's sentry.properties does, because the appender has no attribute for them. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(jul): [Sample Tests 31] Move the JUL sample's system test into sentry-jul (#6323) * test(jul): Move the JUL sample's system test into sentry-jul Adds SentryHandlerIntegrationTest, which configures the Sentry handler through a logging properties file read by LogManager, as the sample does, and checks what reaches MockSentryServer: the warning with its flag, the error with its exception and breadcrumbs, and the logs with their attributes. Its logger is outside io.sentry, whose loggers the handler drops, and the test restores the LogManager configuration the other tests read. The sample has no system tests left, so it comes off the system-test runner and the backend workflow, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 32] Add end-to-end tests of the core APIs and a profiled transaction (#6324) * test(core): Add an end-to-end test of the core APIs over the HTTP transport SentryEndToEndTest reports through the APIs an app uses without integrations and checks what reaches MockSentryServer: messages at the scope's and an explicit level, an exception with its feature flag, an event with a fingerprint, breadcrumbs from an event processor and a beforeBreadcrumb callback, ten events in a row, a transaction with a child span, and metrics with the scope's attributes. It ports the core part of the console sample's system test, which ran the sample's JAR against the Python mock server. The sample's profiling and Kafka parts follow in their own modules. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and check the exception type end to end The console sample's test checked that the captured exception arrives with its type, RuntimeException, not just its value. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(core): Check that the shutdown hook delivers what an app reported before exiting The console samples' system tests ran each sample in its own JVM, asserted that it exited with 0 within 30 seconds, and relied on the shutdown hook to send everything, because the samples never flush or close Sentry. The in-process end-to-end tests flush explicitly, so neither the clean exit nor the hook's flush was tested any more. Run a small app in a child JVM that returns from main without flushing, and check that it exits with 0 and that its event, log and metric arrive. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(async-profiler): Add an end-to-end test of a profiled transaction ContinuousProfilerEndToEndTest starts a sampled transaction with the TRACE profile lifecycle and checks that its profile chunk reaches MockSentryServer, linked to the transaction by the profiler ID. It ports the profiling part of the console sample's system test. The profiler rejects a traces path with a dot anywhere in its absolute form, so the test puts it in the temp dir. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(kafka): [Sample Tests 34] Add an end-to-end test of the raw Kafka client's tracing (#6326) * test(async-profiler): Add an end-to-end test of a profiled transaction ContinuousProfilerEndToEndTest starts a sampled transaction with the TRACE profile lifecycle and checks that its profile chunk reaches MockSentryServer, linked to the transaction by the profiler ID. It ports the profiling part of the console sample's system test. The profiler rejects a traces path with a dot anywhere in its absolute form, so the test puts it in the temp dir. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(kafka): Add an end-to-end test of the raw Kafka client's tracing SentryKafkaEndToEndTest publishes a message through a wrapped KafkaProducer to an in-JVM KRaft broker, consumes it with SentryKafkaConsumerTracing, and checks what reaches MockSentryServer: the queue.publish span in the producing transaction, and a queue.process transaction with the consumer origin and the Kafka system that continues the producer's trace. It ports the Kafka part of the console sample's system test, which needed a Redpanda container. The broker comes from spring-kafka-test 3, which needs Java 17, so the test classpaths resolve Java 17 variants. The tests run on it anyway. With its core, profiling and Kafka parts ported, the console sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the console OTLP sample. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(opentelemetry): [Sample Tests 35] Add an end-to-end test of the agentless OpenTelemetry setup (#6327) * test(opentelemetry): Add an end-to-end test of the agentless OpenTelemetry setup AgentlessEndToEndTest builds the OpenTelemetry SDK through its autoconfiguration, which loads Sentry's customizer, and checks what reaches MockSentryServer: events, a transaction traced through OpenTelemetry with its child span and profile, and metrics. It ports sentry-samples-console-opentelemetry-noagent's system test, which no CI job ran. The customizer only initializes Sentry when the environment asks it to, so the test task sets SENTRY_AUTO_INIT. These are the module's first tests, so it applies the Kotlin plugin and gets an API dump. The sample has no system test left, so it comes off the system-test runner and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and check the exception type in agentless mode Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(opentelemetry): [Sample Tests 36] Add an end-to-end test of the OTLP event linking (#6328) * test(opentelemetry): Add an end-to-end test of the OTLP event linking OtlpEndToEndTest captures a message, a log and a metric inside an OpenTelemetry span with OpenTelemetryOtlpEventProcessor installed, and checks what reaches MockSentryServer: the event carries the span's trace and span IDs, and the log and the metric arrive. It ports the OTLP-specific part of the console OTLP sample's system test, which never checked the link. The sample's other assertions are the console sample's, which SentryEndToEndTest covers. The sample has no system test left, so it comes off the system-test runner and the backend workflow, whose base row moves to the Spring Boot 4 OTLP sample, and drops the Kotlin plugin it only needed for the test. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test(spring-boot): [Sample Tests 37] Move the Boot 4 OTLP sample's tests into the module (#6329) * test(spring-boot): Move the Boot 4 OTLP sample's tests into the module Adds an integrationTestOtlp suite to sentry-spring-boot-4: the servlet app with the OpenTelemetry Spring Boot starter, set up by sentry-opentelemetry-otlp-spring, and OpenTelemetryOtlpEventProcessor. It ports the sample's tests, which were the servlet suite's without OkHttp, and keeps the log and metric attribute checks the sample had dropped. The sample's transactions came from Sentry's own tracing, which CI enabled with SENTRY_TRACES_SAMPLE_RATE, so the suite sets the sample rate the same way. A new test checks what OTLP mode is for: an error in a request carries the request's OpenTelemetry trace. Events point at that trace rather than at Sentry's transaction, so the GraphQL errors are checked next to their transactions instead of by trace ID, as the sample did. The sample has no system tests left, so it comes off the system-test runner. It was the backend workflow's last sample, so the workflow goes too. The Spring Boot 4 matrix runs the new suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and port them to the Boot 4 OTLP suite Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 38] Remove the system-test runner and its Python mock server (#6330) * test: Remove the system-test runner and its Python mock server Every sample's system test now lives in the module it tests, so the Python runner, its mock Sentry server, requirements.txt and the Makefile targets that ran them have nothing left to run. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * test: [Sample Tests 39] Remove the io.sentry.systemtest plugin and sentry-system-test-support (#6331) * test: Remove the io.sentry.systemtest plugin and sentry-system-test-support With the runner gone, nothing applies the io.sentry.systemtest convention plugin or depends on sentry-system-test-support, which held the HTTP and GraphQL clients and the TestHelper the system tests used. The envelope matchers it delegated to stay in sentry-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs: [Sample Tests 40] Describe the in-module end-to-end tests instead of the system tests (#6332) * docs: Describe the in-module end-to-end tests instead of the system tests The e2e_tests rule now covers MockSentryServer, where each kind of end-to-end test lives, the Spring suites per flavor, the OpenTelemetry agent fixture, how to run them and the gotchas the migration found. The test skill runs integration suites by their source set instead of the Python runner, the new_module rule no longer asks for sample tests, and AGENTS.md drops sentry-system-test-support. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * Merge the audit fixes from the branches below, and document the test client and log4j2 suite The context's TestRestTemplate adds trace headers of its own whenever Sentry customizes the RestTemplateBuilder, not only in OpenTelemetry mode, and the Spring Boot modules have an integrationTestLog4j2 suite. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sync main (dd220ac) into 9.x.x. Conflict resolutions: - Take main for files where 9.x.x only carried an older copy of main from the previous squash-merged sync (#6341). - Accept main's deletions of system-tests-backend.yml, requirements.txt and sentry-system-test-support/build.gradle.kts. - Keep the 9.x.x deletions of SentryUserFeedbackButton.java (#6337) and sentry-apache-http-client-5/build.gradle.kts (#6214). - Take main for build.gradle.kts and four Spring Boot 2 sample build files that auto-merged with a stale JDK check or duplicated blocks. - CHANGELOG.md: list the 9.x.x breaking changes under Unreleased and keep main's released sections as they are. Co-Authored-By: Nelson Osacky <nelson.osacky@sentry.io>
sentry-junior
Bot
requested review from
0xadam-brown,
adinauer,
markushi,
romtsn and
runningcode
as code owners
October 27, 2026 09:19
|
Warning Socket is a tool Sentry Security team deployed to defend against supply chain attack. Please provide any feedback you have in #discuss-security slack channel ❤️
|
📲 Install BuildsAndroid
|
9.x.x removed the Logs enable flag (#5939), so Sentry.logger() captures without it. Three tests brought in from main still set it and fail to compile on 9.x.x.
9.x.x ignores logs.enabled (#5939) and enables Logs per integration instead, so the JUL, Log4j2 and Logback integration tests from main sent no logs. Set logsEnabled on the handler/appenders.
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
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.
Weekly sync of
main(dd220ac) into9.x.x, with the merge conflicts from #6384 resolved. This PR replaces #6384, whose head ismainitself, so conflicts couldn't be resolved there without changingmain.Please merge with a merge commit, not a squash. The previous sync (#6341) was squash-merged, so git didn't record the
maincommits it brought in. That's why this week shows 25 conflicts.All resolutions are in the single merge commit
b1c4bad.Conflict resolutions
main(20 files):codeql-analysis.yml,release.yml,spring-boot-{2,3,4}-matrix.yml,CONTRIBUTING.md,build-logic/build.gradle.kts,JdkTargetConvention.kt,gradle/libs.versions.toml, 8 samplebuild.gradle.ktsfiles,MockSentryServer.kt,MockSentryServerTest.kt. In each of these files, the9.x.xversion is byte-identical to an oldermainversion, so no v9-specific content is dropped.main's deletions:.github/workflows/system-tests-backend.yml,requirements.txt,sentry-system-test-support/build.gradle.kts. Same reason as above.9.x.xdeletions:SentryUserFeedbackButton.java(ref(feedback): Remove deprecated user feedback APIs #6337) andsentry-apache-http-client-5/build.gradle.kts(feat(transport): Remove Apache HttpClient transport #6214). Onmain, the only change to these files was a JDK 21 build tweak.mainfor each:build.gradle.ktskept the JDK 21checkthatmainremoved in build: Pin the Gradle daemon to JDK 21 #6364.sentry-samples-spring-boot,-webflux,-opentelemetry,-opentelemetry-noagent) ended up with duplicatedcompileJava/compileKotlinblocks.Needs review:
CHANGELOG.mdThe changelog on
9.x.xwas already out of order: itsUnreleasedsection repeated entriesmainreleased in 8.61.1, and the v9 breaking changes (#5939, #6214, #6096) sat under## 8.60.0. This PR proposes:## Unreleased→### Breaking Changeslists only the v9 changes (ref(feedback): Remove deprecated user feedback APIs #6337, feat(core): Remove Logs and Metrics enable flags #5939, feat(transport): Remove Apache HttpClient transport #6214, fix(android): Decide session rotation on a monotonic clock (JAVA-573) #6096).main's released sections, unchanged.Compared with
main, the changelog only gains theUnreleasedblock. No9.x.xchangelog lines are dropped. Please confirm this layout or suggest another.Sanity check
Apart from
CHANGELOG.md, the files that differ frommainare all touched by the v9-only commits (#5939, #6214, #6096, #6337), plusSentryClientInternalEventProcessorTest.kt, which dropslogs/metrics.isEnabledas part of the v9 change in #5939. I didn't run a local build; CI on this PR is the check.via no.
--
View Junior Session [Sentry]