November 2026 Summaries

Sentry traced recurring symbolication latency incidents to a Postgres database storing source-map artifact bundles, where a small number of incorrectly named releases, including literal unexpanded CI variables such as “VERCEL_GIT_COMMIT_SHA” and “undefined,” accumulated millions of files and URL-index rows. Legacy source-map lookups based on release name and URL could attempt unbounded scans of these oversized releases, even though generated filenames could never match, and retries compounded the database load. Investigation, conducted through controlled queries on read replicas with AI assistance and engineer review, identified a worst-case release containing 13,595 bundles, 44 million URL-index rows, and lookups lasting minutes. The most consequential fix capped URL lookup scans at one million rows and cached misses, reducing peak database CPU from 76% to 19% and symbolicator timeouts by 98%; additional improvements split costly debug-ID queries, avoided rewriting index rows during bundle renewals, stopped indexing generated filenames, and disabled inefficient Postgres JIT compilation. The incident underscored the importance of bounding per-request database work, preventing futile retries, and ensuring CI environment variables are correctly expanded when assigning release names.

Using a coding agent connected to Sentry’s MCP and trace data, Sentry engineers identified and fixed numerous backend performance bottlenecks through mostly small code changes, collectively eliminating hundreds of millions of database queries per week and dramatically accelerating several expensive operations. The agent ranked high-volume and slow spans from Django instrumentation, cache calls, RPCs, tasks, and API routes, then investigated candidate fixes using source code, Git history, trace examples, and read-only database validation with EXPLAIN ANALYZE. Improvements included avoiding unnecessary repository pagination, removing duplicate queries, reusing loaded project data, eager-loading related objects, adding an index, batching cache writes, and restructuring a GroupHistory query to use existing indexes more effectively, reducing one warm-cache lookup from 935 ms to 0.4 ms. Reported results included lower database load, reduced disk reads, faster ingestion and issue-status updates, tens of millions fewer daily queries, and cache operations reduced from roughly 51 ms to 1.2 ms in one case. The approach emphasizes starting with broad natural-language prompts, narrowing to promising areas, assessing risks before edits, and validating performance changes against database plans and production metrics.

Starting with Sentry Android SDK 8.51.0, continuous profiling on Android 15 and newer automatically uses Perfetto through Android’s ProfilingManager API instead of the in-process Debug.startMethodTracing legacy tracer, while older devices retain legacy profiling by default. The change is intended to prevent tracer-related crashes, reduce application CPU and memory overhead by moving most profiling work into a system process, and produce more representative performance data. Developers can download raw Perfetto traces from Sentry for further inspection in the Perfetto UI, and profiles can reveal issues such as expensive JSON parsing on the main thread that causes UI freezes. ProfilingManager is available only on Android 15+ devices, estimated at about 41% of active devices, and Android system rate limits mean that not every eligible session will be profiled even at a 100% sample rate. Upgrading requires no configuration changes for existing continuous-profiling users, though developers may disable legacy profiling with the enableLegacyProfiling option to profile only Android 15+ devices with Perfetto.