Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Clean up profile and replay artifacts on pre-envelope drops

Đang mở
#6,153 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java, kotlin

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Kotlin
Star
1.4k
Fork
478
Merge trung bình
2 ngày 20 giờ
Pull request đã merge (30 ngày)
71

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của getsentry/sentry-java

Tất cả issue của getsentry/sentry-java

Issue tương tự

Thêm issue về Kotlin

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.