Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Clean up profile and replay artifacts on pre-envelope drops

未關閉
#6,153 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
45/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
java, kotlin

研究方向

The issue is in SentryClient's capture flow, specifically around envelope construction and sidecar file cleanup. Look at SentryClient, SentryEnvelopeItem.fromProfilingTrace, and SentryEnvelopeItem.fromReplay. The tests to add will involve temporary files and mocking EventProcessor and beforeSend callbacks. 'Done' means profile trace files and replay videos/folders are deleted on early drops, and discard reasons are correctly accounted for.

由索引模型根據 Issue 內容生成。

描述

Platform: Java Profiles

Problem

SentryClient currently relies on lazy envelope-item serialization to clean up file-backed transaction profiles and replay recordings. If capture terminates after those sidecars exist but before envelope construction, serialization never takes ownership and the files are not promptly deleted.

This affects both EventProcessor and beforeSend* drop paths. PR #6142 adds new fail-closed exits when an EventProcessor throws, but the same ownership gap already exists for intentional processor drops and beforeSend* drops.

Affected paths

Profiled transactions

A profiled transaction can return before buildEnvelope(..., profilingTraceData) when:

  • an EventProcessor returns null;
  • an EventProcessor throws and the SDK fails closed;
  • beforeSendTransaction returns null; or
  • beforeSendTransaction throws.

The profile trace is normally deleted by the lazy serializer created in SentryEnvelopeItem.fromProfilingTrace. These early returns prevent that cleanup, allowing sensitive profile data and disk usage to accumulate in long-running Android apps or JVM services.

Session replays

A replay can return before replay envelope construction when:

  • an EventProcessor returns null;
  • an EventProcessor throws and the SDK fails closed;
  • beforeSendReplay returns null; or
  • beforeSendReplay throws.

Replay cleanup currently occurs in the serializer created by SentryEnvelopeItem.fromReplay. Bypassing it can retain the replay video or, for a backfilled replay, the entire replay folder.

Expected behavior

Introduce explicit ownership for file-backed sidecars so every terminal pre-envelope drop either:

  1. transfers the sidecar to an envelope item that owns serialization and cleanup; or
  2. disposes of the sidecar immediately at the capture boundary.

The implementation should:

  • delete abandoned profile trace files;
  • delete normal replay videos and the correct backfilled replay folder;
  • record one dropped profile with the same discard reason as its transaction (event_processor, before_send, or callback_error);
  • avoid double deletion and double accounting; and
  • preserve existing replay-folder semantics and transaction/span discard quantities.

Tests

Add real temporary-file regression coverage for:

  • profiled transactions dropped by processor null and processor exception;
  • profiled transactions dropped by beforeSendTransaction null and exception;
  • normal replay videos dropped by processor and beforeSendReplay paths;
  • backfilled replay folders dropped by processor and beforeSendReplay paths; and
  • DataCategory.Profile accounting under each corresponding discard reason.

Context

This was identified while reviewing #6142. The fail-closed processor behavior is correct; the issue is that cleanup is coupled to envelope serialization even though several valid terminal paths return before an envelope is built.

主要語言
Kotlin
星號
1.4k
分支
478
平均合併
2 天 20 小時
30 天內合併 PR
71

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

getsentry/sentry-java 的其他 Issue

查看 getsentry/sentry-java 的全部 Issue

相似的 Issue

更多 Kotlin Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。