Add delete-data, create-report, and breadcrumbs

[krassx]

Summary

• Add DeleteCollectedDataOnDevice, CreateReport, and AddBreadcrumb. iOS delete hops to the main thread. An already-open iOS report throws. Editor CreateReport is unsupported.
• Buffer iOS AddNetworkEvent until launch, flush FIFO, and drop the buffer on stop. Android still submits immediately through channelAddNetwork.
• iOS channel network and breadcrumb exports use the channel stored at wrapper registration. Live iOS reports apply changes, including attachments, back onto the native report.

Test plan

• DOTNET_ROLL_FORWARD=LatestMajor dotnet test Tests~/WrapperPolicy/Bugsee.WrapperPolicy.Tests.csproj --filter "PublicApiSourceTests|NetworkEventLaunchBufferTests|ChannelSubmitTests" (21 passed before the cast fix; PublicApiSourceTests 16/16 after)
• Full WrapperPolicy suite was 93/93 before the cast-only follow-up
• CI wrapper, Android, and iOS jobs on this PR

Made with Cursor

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

This PR adds the public DeleteCollectedDataOnDevice / CreateReport / AddBreadcrumb / Upload(IReport) surface, live-applies iOS CreateReport mutations onto a native open report, and buffers iOS wrapper-channel network events until Launched.

I reviewed the diff against the existing report-handler apply path (BugseeUnityApplyReportDict), IReport/IosReport serialization, Android createReport/upload, lifecycle fan-out, and the new buffer — not the patch alone.

P0: none

P1 High — iOS CreateReport is a process-wide singleton with no public discard

Location: Runtime/Platform/IOS/IOSBridge.cs:141, Runtime/Bugsee.cs:91, IosLiveReport.Dispose at IOSBridge.cs:510

Problem: iOS allows only one native open report (gOpenReport + _openReportHandle). The public type is IReport, which is not IDisposable. IosLiveReport implements Dispose, but Bugsee.CreateReport() is declared as IReport, so using (var r = Bugsee.CreateReport()) does not compile and there is no Discard API. Dropping the handle without Upload leaves native+managed locks set until Stop.

Impact: A cancelled in-game reporter bricks every later CreateReport with InvalidOperationException: a report is already open. Android has no such exclusive slot.

Scenario: OnBug() creates a report and shows UI. User hits Cancel and the IReport is dropped. Next OnBug() throws. Uncaught, that takes down the reporting flow for the rest of the session.

Fix: Release the previous native report on a second CreateReport (or snapshot C# state and bind native only at Upload). Expose discard on the public type (IReport : IDisposable or Bugsee.Discard(IReport)). Do not rely on an internal Dispose the compiler cannot see.

P1 High — live iOS apply uses optional off-protocol attachment APIs and re-runs on every setter

Location: Plugins/iOS/BugseeUnityBridge.mm:95-128, IOSBridge.IosLiveReport setters / CreateAndAddAttachment at :518 and :601

Problem: IosLiveReport calls _bugsee_apply_open_report on every field and attachment mutation. IosReport.ToResultJson() always emits "attachments":[...]. The new apply path then:

• calls clearAttachments only if respondsToSelector (not on BGSReportContract; clearLabels / clearAllAttributes are direct protocol calls)
• re-adds via optional addAttachmentWithData:name:mimeType: / addAttachmentWithFilePath:...
• ignores fileName

The report-handler path in BugseeUnityCallbacks.mm (BugseeUnityApplyReportDict) already uses protocol createAndAddAttachmentWithName: and sets fileName. A source test in this PR forbids that selector here.

Impact: If clearAttachments is missing, each SetData / Summary set appends another copy of every attachment. If addAttachmentWithData:... is missing, C# looks like it attached bytes and native upload has none. Filename never reaches native.

Scenario: var a = report.CreateAndAddAttachment("log"); a.Filename = "log.txt"; a.SetData(bytes); report.Summary = "stuck"; Bugsee.Upload(report); — empty apply, then data apply, then summary apply. Without a guaranteed clear, native ends up with duplicate attachments; without the add selector, none.

Fix: Apply native state once at Upload (C# already holds the snapshot). For attachments, reuse createAndAddAttachmentWithName: + fileName / mimeType / data from the handler path. If you must live-apply, fail closed when clearAttachments is absent instead of appending.

P2 Medium — Android CreateReport wraps a null Java report

Location: Runtime/Platform/Android/AndroidBridge.cs:450-454

Problem: No null check on createReport. iOS throws InvalidOperationException("CreateReport failed.").

Impact / scenario: CreateReport() before Launch (or whenever Java returns null) yields AndroidReport(null). First Summary/Upload is a NullReferenceException instead of a typed failure.

Fix: If javaReport == null, throw the same InvalidOperationException as iOS.

P2 Medium — Android delete is a silent no-op while launched; iOS deletes

Location: Runtime/Platform/Android/AndroidBridge.cs:443-447 vs IOSBridge.cs:137 / _bugsee_delete_collected_data

Problem: The public API is one void method. Android returns immediately when GetLaunched() is true. iOS always hops to main and calls [Bugsee deleteCollectedDataOnDevice].

Impact: A GDPR/logout wipe that is only tested on iOS leaves Android session data on disk. Callers cannot tell it was skipped.

Scenario: Bugsee.DeleteCollectedDataOnDevice() during an active session (common logout path).

Fix: Throw if launched, or Stop then delete. Do not swallow a destructive privacy call.

P2 Medium — iOS network launch buffer is not thread-safe

Location: Runtime/WrapperPolicy/NetworkEventLaunchBuffer.cs:26-62, IOSBridge.AddNetworkEvent / NotifyLifecycle

Problem: List<T> with no lock. Enqueue is on the caller thread; SetPhase runs from lifecycle on the Unity main thread. This shared mutable buffer is new in this PR.

Impact: IndexOutOfRangeException / list corruption, or lost events around Launch/Stop.

Scenario: Custom AddNetworkEvent from a UnityWebRequest completed callback (worker thread) overlapping Launch/Stop/Launched.

Fix: One lock around phase + pending, or marshal Enqueue onto the main thread before touching the list.

---

Verdict

1. Overall risk: High
2. Merge recommendation: Request changes
3. Must-fix: iOS exclusive CreateReport with no discard; live attachment apply via optional selectors on every setter
4. Also fix: Android null createReport; silent Android delete; unsynchronized network buffer

I did not run the WrapperPolicy tests here (dotnet is not installed in this environment). The new tests are mostly source-string assertions; they would not have caught these runtime paths.

What looks solid: BreadcrumbLevelMap.ParseOrThrow fail-closed on both platforms; iOS delete hops to main; editor CreateReport/Upload(IReport) throw NotSupportedException; network submit stays on gChannel with ToNativeMapJson for headers; FIFO buffer tests match the intended launch/stop phases.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of a74b63f (prior pass was 698c632). I checked the new public API against iOS/Android 7.x docs, the existing report-handler apply path (BugseeUnityApplyReportDict), IosReport serialization, Stop completion behavior, and the launch buffer — not the patch alone.

Prior findings: exclusive native CreateReport / no discard, live-apply optional attachment selectors, Android null createReport, and the unsynchronized buffer are addressed. Android delete-while-launched is only partially addressed (see P1/P2 below).

P0: none

P1 High — iOS delete runs before native stop: finishes

DeleteCollectedDataOnDevice calls Stop() then _bugsee_delete_collected_data(). iOS Stop issues [Bugsee stop:nil] and invokes its managed completion on the same turn. _bugsee_stop does not wait. BugseeRunOnMain then runs deleteCollectedDataOnDevice:YES immediately because this is already the main thread.

iOS 7.x cleanup and the 7.x migration require delete inside the stop: completion (Recording must be stopped with +[Bugsee stop:] before calling it). A logout wipe while launched — the intended use of this new API — races with teardown and can leave session video/logs on disk. The native completion is nil, so the caller cannot see success=NO.

P2 Medium — Android delete is the wrong 7.3 signature

Same C# shape: Stop() then CallStatic("deleteCollectedDataOnDevice") with no args. Android 7.3 documents deleteCollectedDataOnDevice(true, callback) — true wipes intermediate capture data, matching iOS :YES. A no-arg JNI lookup either throws NoSuchMethodError or hits a leftover that defaults includingIntermediate=false, so a GDPR wipe that works on iOS leaves Android capture buffers. Stop(Action) already exists and maps to stop(Runnable) (“fully stopped”); use that, then the two-arg delete.

P2 Medium — iOS upload apply still drops fileName

IosAttachment.ToJsonObject() emits fileName. BugseeBridgeApplyReportDict only passes name into addAttachmentWithData:name:mimeType: / addAttachmentWithFilePath:.... The report-handler path in BugseeUnityCallbacks.mm already does createAndAddAttachmentWithName: and sets fileName. IAttachment.Filename is a public setter; Android honors setFileName.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: nest iOS delete inside the native stop: completion; call Android deleteCollectedDataOnDevice(true, cb) after stop has finished
4. Also fix: apply fileName the same way the handler path does

I did not run WrapperPolicy tests (dotnet is not on PATH). The new tests are source-string assertions and would not catch the stop/delete race or the missing fileName apply.

What looks solid: createReportWithCompletion + apply-once at upload; public Discard; Android null createReport now throws; network buffer is locked; breadcrumbs fail-closed via ParseOrThrow; iOS delete at least uses the 7.x :YES selector.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 0dc19cf (prior a74b63f, 698c632). I checked the new stop-then-delete helper against iOS 7.x cleanup docs, Android 7.3 deleteCollectedDataOnDevice(true, callback), and the still-unchanged apply path.

Addressed since last pass: iOS delete is now [Bugsee stop:^{ deleteCollectedDataOnDevice:YES }] via _bugsee_stop_then_delete_collected_data. Android waits on Stop(callback) and passes true for intermediate data.

P0 / P1: none

P2 Medium — Android delete callback is Runnable, not the 7.3 success consumer

InvokeDeleteCollectedDataOnDevice calls CallStatic("deleteCollectedDataOnDevice", true, new RunnableProxy(...)). RunnableProxy is java.lang.Runnable. The documented 7.3 API is deleteCollectedDataOnDevice(true, success -> { ... }) — a Boolean consumer (Boolean.TRUE.equals(success)). Unity JNI matches the proxy interface, so this either throws NoSuchMethodError after stop has already completed, or never receives the success flag.

P2 Medium — iOS upload apply still drops fileName

Unchanged from last pass. IosAttachment.ToJsonObject() emits fileName; BugseeBridgeApplyReportDict only passes display name into addAttachmentWithData:name:mimeType:. The handler path sets created.fileName.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: Android delete callback type; apply fileName on iOS upload

I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: iOS stop-then-delete sequencing now matches the 7.x docs; managed exclusive report + Discard; apply-once at createReportWithCompletion; locked network buffer; Android null createReport throws.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b1a6d56 (prior 0dc19cf, a74b63f, 698c632).

Addressed in this commit: Android delete now uses BooleanConsumerProxy (java.util.function.Consumer / accept(Boolean)), matching the 7.3 success -> callback, and logs on failure. iOS BugseeBridgeApplyReportDict reads fileName and passes it into addAttachmentWithData: / addAttachmentWithFilePath: (falls back to display name when empty).

P0–P3: none remaining. All earlier findings (exclusive native report, live-apply, null createReport, buffer lock, iOS stop-then-delete, Android no-arg delete) stay addressed.

Residual only: addAttachmentWithData:name:mimeType: has a single name slot, so a distinct display Name and Filename collapse. That is inherent to the beta5 selector this path uses; the download name now reaches native.

---

Verdict

1. Overall risk: Low
2. Merge recommendation: Approve
3. Must-fix: none

I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: public Discard; apply-once at createReportWithCompletion; iOS delete nested in stop:; Android Stop(callback) then deleteCollectedDataOnDevice(true, Consumer); locked launch buffer; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b1a6d56 (prior 0dc19cf, a74b63f, 698c632). I checked the new public API against iOS 7.x cleanup/create-report docs, the handler apply path (BugseeUnityApplyReportDict), IosReport serialization, Android 7.3 delete, and the launch buffer — not the patch alone.

Addressed since last pass: Android delete now passes BooleanConsumerProxy (java.util.function.Consumer) after Stop(callback). iOS apply now reads JSON fileName (still incomplete — see P2).

P0 / P1: none

P2 Medium — iOS UploadReport is not fenced by Discard / Stop / Delete

UploadReport snapshots JSON and starts createReportWithCompletion asynchronously, but leaves _openReportHandle set until FinishManagedReportUpload. DiscardReport only nulls the slot. Stop / DeleteCollectedDataOnDevice null _pendingManagedReportUpload and return; they do not cancel native work.

FinishManagedReportUpload then unconditionally clears _openReport / _openReportHandle. Native _bugsee_upload_managed_report still calls uploadReport: after the managed callback, even if Stop/Delete already ran.

P2 Medium — iOS apply still does not set attachment fileName

IosAttachment.ToJsonObject() emits both name and fileName. IAttachment and Android (setName / setFileName) treat them as distinct (display vs download). The handler path already does createAndAddAttachmentWithName: + created.fileName. This apply path stuffs fileName into addAttachmentWithData:name: and never sets the fileName property. The source test still forbids the handler selector.

P2 Medium — Stop(callback) then Delete still races on iOS

DeleteCollectedDataOnDevice while launched correctly uses [Bugsee stop:^{ deleteCollectedDataOnDevice:YES }]. After Stop(), _launched is already false and Stop's callback runs on the same turn ([Bugsee stop:nil]). The official cleanup sample translated to Unity — Bugsee.Stop(() => Bugsee.DeleteCollectedDataOnDevice()) — therefore takes the not-launched path and deletes immediately.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: fence iOS Upload (generation token / clear slot at submit; do not wipe a newer handle; do not uploadReport after Stop/Delete)
4. Also fix: set fileName on the created attachment; make Stop+Delete use the native stop completion

I did not run WrapperPolicy tests (dotnet is not on PATH). The new tests are source-string assertions and would not catch the Discard/Stop race or Name vs Filename.

What looks solid: Android BooleanConsumerProxy + true after stop(Runnable); iOS stop-then-delete when Delete is called while launched; managed exclusive report + public Discard; apply-once at createReportWithCompletion; locked network buffer; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 094a11d (prior b1a6d56). I checked the new generation token / gCancelManagedReportUpload path and the unified _bugsee_delete_collected_data stop-chain against the remaining Discard/Stop/Delete races.

Addressed: Stop(() => Delete()) is now safe — delete itself does [Bugsee stop:^{ delete… }] whenever sharedInstance != nil. C# generation prevents FinishManagedReportUpload from clearing a handle after Stop/Delete with no follow-up Upload. Discard/Stop/Delete set the native cancel flag.

P0 / P1: none

P2 Medium — next Upload clears the cancel flag for an in-flight create

_bugsee_upload_managed_report sets gCancelManagedReportUpload = NO on entry. UploadReport still holds _openReportHandle until the async callback, so the next CreateReport throws “already open” and the natural unlock is Discard then a new report.

Discard + CreateReport + Upload of report B resets the global cancel flag while report A’s createReportWithCompletion is still running. A’s completion then applies A and uploadReport:s it (cancelled report still leaves the device), then OnManagedReportCreateCompletion sees B’s pending/generation and FinishManagedReportUpload wipes B’s handle.

Residual only (not blocking): apply still passes fileName as the single name: slot, so a distinct display Name collapses.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: per-upload native token (or do not reset cancel on a new upload until in-flight completions have seen it); clear the managed slot when JSON is snapped at UploadReport

I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: delete always stop-chains when the SDK instance is alive; C# generation; Android BooleanConsumerProxy; locked network buffer.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 094a11d (prior b1a6d56, 0dc19cf, a74b63f, 698c632). Checked against iOS 7.x createReportWithCompletion / stop:+delete, the handler apply path (BugseeUnityApplyReportDict), IosReport.ToResultJson(), Android 7.3 delete/createReport, and the launch buffer — not the patch alone.

Addressed in this commit: Stop(() => DeleteCollectedDataOnDevice()) now hits _bugsee_delete_collected_data, which does [Bugsee stop:^{ deleteCollectedDataOnDevice:YES }] whenever sharedInstance is still non-nil. Stop/Delete-only also set gCancelManagedReportUpload and drop _pendingManagedReportUpload, so a lone in-flight create no longer uploadReport:s after teardown.

P0: none

P1 High — Discard + second Upload still uploads the discarded report and wipes the new handle

The generation token never reaches native. _bugsee_upload_managed_report resets a process-wide gCancelManagedReportUpload = NO, and OnManagedReportCreateCompletion always binds to the current _pendingManagedReportUpload / _pendingUploadGeneration. UploadReport also leaves _openReportHandle set, so a second CreateReport throws until native completes — the only unlock is Discard, which is this race.

P2 Medium — iOS apply still collapses attachment Name / Filename

Unchanged. addAttachmentWithData:name: gets fileName only; display name is dropped. The handler path still sets both via createAndAddAttachmentWithName: + created.fileName.

P2 Medium — CreateReport with unset Severity applies wire 0

Empty IosReportDto.severity is 0. ToResultJson() always emits it; apply always writes report.severity. IssueSeverity / IssueSeverityWire start at 1. Android createReport keeps the native default.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: per-upload native generation (do not reset a global cancel; do not attribute a stale createReportWithCompletion to the current pending); clear the managed slot once JSON is snapshotted; on cancel, do not uploadReport: that native report
4. Also fix: set both attachment name and fileName; omit/skip severity 0

I did not run WrapperPolicy tests (dotnet is not on PATH). The new tests are source-string assertions and would not catch the overlapping-upload race or Name vs Filename.

What looks solid: Android BooleanConsumerProxy + true after stop(Runnable); iOS delete now stop-then-wipe when an instance exists (including after C# Stop); managed exclusive report + public Discard; apply-once at createReportWithCompletion; locked network buffer; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 39f218a (prior 094a11d).

Addressed: Native upload is keyed by uploadId / gActiveManagedReportUploadId. Completions whose token is no longer active skip apply/uploadReport:. UploadReport clears _openReport / _openReportHandle when JSON is snapped, so a second CreateReport does not need Discard. Apply now adds with display name and sets fileName on BGSAttachmentContract when the two differ. Stop/Delete cancel only the matching in-flight token.

P0–P3: none remaining.

Residual: a second Upload while the first createReportWithCompletion is still running last-wins (the first token is deactivated, no error). That matches the removed “upload already in progress” guard.

---

Verdict

1. Overall risk: Low
2. Merge recommendation: Approve
3. Must-fix: none

I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: per-upload cancel; slot released at submit; stop-chained delete; Android BooleanConsumerProxy; distinct attachment names; locked network buffer.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 39f218a (prior 094a11d). Checked the per-upload id, slot-clear at UploadReport, and BugseeBridgeSetAttachmentFileNameIfNeeded against beta5 BGSContracts / createReportWithCompletion: — not the patch alone.

Addressed: The Discard-then-reupload race is gone: JSON is snapshotted, the managed slot is cleared, and completions carry uploadId so a stale create does not wipe a new handle or uploadReport: after Stop/Delete. Attachment apply now passes display name: and sets fileName on the returned BGSAttachmentContract (beta5 addAttachmentWithData: does return the attachment). Stop(() => Delete()) still stop-chains when sharedInstance is live.

P0: none

P1 High — second Upload(IReport) silently cancels the first in-flight create

gActiveManagedReportUploadId = uploadId is still one slot. Overlapping CreateReport + Upload (now allowed; the “already in progress” guard was removed) drops report 1. Android keeps both.

P2 Medium — unset CreateReport Severity still applies wire 0

Unchanged. Cocoa BugseeSeverityLevel starts at 1. ToResultJson() always emits 0 from an empty dto.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: track each upload id independently (set/queue), do not overwrite the active id; skip/omit severity 0

I did not run WrapperPolicy tests (dotnet is not on PATH). I did inspect Bugsee 7.0.0-beta5 headers (addAttachmentWithData: returns the attachment; createReportWithCompletion: is documented off the main thread).

What looks solid: per-id callback; managed slot cleared at submit; fileName override after add; Android BooleanConsumerProxy; stop-then-delete; locked network buffer.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 39f218a. I checked the new per-upload token / fileName path against iOS createReportWithCompletion and against the bugsee-android 7.3.0 AAR (javap of Bugsee, BugseeExchangeFactory, Breadcrumb$Level) — not the patch alone.

Addressed: Discard + second Upload no longer uploads the discarded snapshot; UploadReport clears the managed slot immediately; attachment display name and fileName are applied separately; Stop/Delete still stop-chain before wipe.

P0: none

The three new Android public APIs in this PR do not match 7.3.0 JNI. Each throws AndroidJavaException on first use. iOS still last-write-wins when two Upload(IReport) calls overlap.

---

Verdict

1. Overall risk: High
2. Merge recommendation: Request changes
3. Must-fix: Android createReport(ReportCreationListener), deleteCollectedDataOnDevice(boolean, Callback1<Boolean>), and breadcrumb factory/Level JNI; keep in-flight iOS uploads independently live
4. Also: do not block the Unity main thread waiting for Android onCreated if that callback is posted to main — bind native at Upload like iOS, or complete in the listener

I inspected com.bugsee:bugsee-android:7.3.0 classes.jar. I did not run WrapperPolicy tests or a device JNI session. The new tests are source-string assertions and would not catch these signatures.

What looks solid: iOS per-upload token vs a process-wide cancel flag; apply-once at createReportWithCompletion; distinct attachment name/fileName; locked network buffer; upload(Report) on Android is the correct 7.3.0 overload; breadcrumbs fail-closed via ParseOrThrow.

Unset iOS Severity serializing 0 is not a user-facing clobber: 7.x ignores values outside 1–5 and keeps the native default.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of e49f387 (prior 39f218a). iOS overlapping uploads now use a fence + cancelled-id set instead of a single active id. Android public APIs in this PR are unchanged; I checked them with javap on com.bugsee:bugsee-android:7.3.0 classes.jar.

Addressed: Two Upload(IReport) calls on iOS both stay live until Stop/Delete increments gManagedReportUploadFence. The discarded-snapshot / wiped-handle races stay fixed. Attachment name / fileName stay distinct.

P0: none

P1 High — Android 7.3.0 JNI still does not match this PR

Unchanged in this commit. All three new Android entry points throw AndroidJavaException on first use:

• CreateReport — no-arg createReport(); AAR is void createReport(ReportCreationListener)
• DeleteCollectedDataOnDevice — java.util.function.Consumer; AAR is Callback1<Boolean> (void run(T))
• AddBreadcrumb — Level.fromRawValue + 4-arg createBreadcrumb; AAR is fromValue(byte) / valueOf and 0-arg or 6-arg factory

---

Verdict

1. Overall risk: High
2. Merge recommendation: Request changes
3. Must-fix: Android createReport(ReportCreationListener), deleteCollectedDataOnDevice(boolean, Callback1<Boolean>), and breadcrumb Level/factory JNI. Bind native report at Upload like iOS; do not block Unity main waiting for onCreated if it posts to main.

I inspected com.bugsee:bugsee-android:7.3.0 classes.jar. I did not run WrapperPolicy tests (dotnet is not on PATH) or a device JNI session.

What looks solid: iOS independent upload ids + fence on Stop/Delete; apply-once at createReportWithCompletion; distinct attachment names; locked network buffer; Android upload(Report) overload exists; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Re-review of 39f218a. Prior iOS lifecycle / upload-token / attachment / buffer-lock findings are closed. This pass independently javap'd com.bugsee:bugsee-android:7.3.0 (classes.jar from Maven Central). The new public Android APIs do not match that AAR, so CreateReport, AddBreadcrumb, and DeleteCollectedDataOnDevice throw AndroidJavaException before any null-check can run. Requesting changes.

P1 (3, all Android 7.3.0 JNI)

1. CreateReport calls no-arg createReport(). 7.3.0 only has void createReport(ReportCreationListener) (onCreated on the main thread; null if not launched).
2. deleteCollectedDataOnDevice is invoked with java.util.function.Consumer. AAR: (ZLcom/bugsee/library/contracts/common/Callback1;)V. Existing EventFilterProxy already uses Callback1.run.
3. AddBreadcrumb calls Level.fromRawValue (LogLevel API) and 4-arg createBreadcrumb. AAR: fromValue(byte) and createBreadcrumb() or 6-arg (long, String, String, Level, String, Map).

Residual (not blocking): one gActiveManagedReportUploadId still last-write-wins if two iOS Uploads overlap. Serial in-game reporter is fine.

PublicApiSourceTests currently asserts the same incorrect JNI strings, so unit tests stay green while the player throws.

Risk: High. Merge: Request changes.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of e49f387 (prior 39f218a). I checked the new public API against iOS createReportWithCompletion / stop-then-delete, and against bugsee-android 7.3.0 classes.jar (javap of Bugsee, BugseeExchangeFactory, Breadcrumb$Level, Callback1, ReportCreationListener) — not the patch alone.

Addressed in this commit: overlapping iOS Upload(IReport) is no longer last-write-wins. _bugsee_upload_managed_report keeps each uploadId independently live; Stop/Delete bump gManagedReportUploadFence instead of replacing a single active id. The old gActiveManagedReportUploadId path is gone.

P0: none

The three new Android public APIs still do not match 7.3.0 JNI. Each throws AndroidJavaException on first use, so Delete / CreateReport / AddBreadcrumb are dead on Android while iOS works.

---

Verdict

1. Overall risk: High
2. Merge recommendation: Request changes
3. Must-fix: Android createReport(ReportCreationListener), deleteCollectedDataOnDevice(boolean, Callback1<Boolean>), and breadcrumb Level.fromValue / 6-arg createBreadcrumb
4. When wiring createReport(listener): do not block the Unity main thread waiting for onCreated — that callback is posted to Android main (the Unity thread). Match iOS: managed snapshot at CreateReport, bind native at Upload.

I inspected com.bugsee:bugsee-android:7.3.0 from Maven Central. I did not run WrapperPolicy tests. The new tests are source-string assertions (BooleanConsumerProxy, fromRawValue is untested) and would not catch these signatures — Android_delete_collected_data_stops_then_deletes currently requires the wrong callback type.

What looks solid: iOS independent upload tokens + fence cancel; apply-once at createReportWithCompletion; distinct attachment name / fileName; stop-chained delete; locked network launch buffer; upload(Report) on Android is the correct 7.3.0 overload; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 2506581 (prior e49f387). Android now snapshots C# at CreateReport and binds native via createReport(ReportCreationListener) at Upload. I checked the new JNI against javap of com.bugsee:bugsee-android:7.3.0 (createReport(ReportCreationListener), deleteCollectedDataOnDevice(boolean, Callback1), Level.fromValue(byte), 6-arg createBreadcrumb).

Addressed: The three Android 7.3.0 JNI P1s. BooleanCallback1Proxy implements Callback1.run; breadcrumb uses fromValue + type "manual" + HashMap; ReportCreationListenerProxy.onCreated applies then upload(Report) without blocking Unity main. iOS overlapping-upload fence stays in place.

P0 / P1: none

P2 Medium — Android ApplyTo wipes native snapshot fields the user never set

Always writes Email ?? "" and ClearAllAttributes / ClearLabels / ClearAttachments. iOS omits those keys when unset so session email/attributes on the native report survive.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: apply only fields the C# snapshot actually set (especially email and attributes)

I inspected the 7.3.0 AAR earlier this run. I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: JNI signatures now match 7.3.0; managed snapshot at CreateReport / native bind at Upload on both platforms; Callback1 delete; 6-arg breadcrumb factory; iOS independent upload ids + stop-then-delete; distinct attachment names.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Re-review of 2506581 (prior e49f387). Independently javap'd com.bugsee:bugsee-android:7.3.0 again.

Closed (the three Android JNI P1s)

• createReport(ReportCreationListener) + managed snapshot at CreateReport / bind at Upload — no Unity-main wait
• deleteCollectedDataOnDevice(boolean, Callback1<Boolean>) via BooleanCallback1Proxy.run
• Breadcrumb.Level.fromValue(byte) (values 1–5 match ToAndroid) and 6-arg createBreadcrumb(..., "manual", HashMap)
• iOS overlapping uploads remain independent (e49f387 fence + cancelled-id set)

P0: none

P1: AndroidManagedReport.ApplyTo always ClearAllAttributes() / ClearAttachments() and writes Email ?? "". Native createAndPrepareBugReport has already filled the Report (session attributes, handler attachments). iOS ToResultJson omits attributes unless the user touched them for this reason.

Residual: Android Stop/Delete does not fence an in-flight createReport listener the way iOS bumps gManagedReportUploadFence.

Risk: Medium. Merge: Request changes.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 2506581 (prior e49f387). I checked the new Android managed-snapshot path against bugsee-android 7.3.0 classes.jar (javap of Bugsee, BugseeExchangeFactory / f0.createBreadcrumb, Breadcrumb$Level.fromValue, Callback1, ReportCreationListener, BugseeIssueReportingCoordinator.createAndPrepareBugReport) and against the iOS apply-once / upload-fence path — not the patch alone.

Addressed in this commit: the three Android 7.3.0 JNI mismatches are gone.

• CreateReport is a managed snapshot; Upload calls void createReport(ReportCreationListener) and does not block Unity main waiting for onCreated (that callback is posted to Android main).
• Delete uses Callback1 (BooleanCallback1Proxy.run(AndroidJavaObject) → booleanValue), matching (ZLcom/bugsee/library/contracts/common/Callback1;)V.
• Breadcrumbs use Level.fromValue(byte) (1–5 = DEBUG…FATAL) and the 6-arg factory (timestamp, category, message, level, type, data) — bytecode is setCategory / setMessage / setLevel / setType / setData.

Prior iOS findings stay addressed: independent upload ids + gManagedReportUploadFence, apply-once at createReportWithCompletion, distinct attachment name / fileName, stop-chained delete, locked network buffer.

P0: none

The new Android bind-at-upload path still has two happy-path / lifecycle bugs that iOS already avoided.

---

Verdict

1. Overall risk: High
2. Merge recommendation: Request changes
3. Must-fix: do not ClearAllAttributes / force Email="" onto a native report that already copied session attributes and getUserIdentifier(); fence in-flight onCreated → upload(Report) across Stop/Delete the same way iOS fences uploadReport:
4. Also: skip unset Summary/Description (null) instead of writing ""

I inspected com.bugsee:bugsee-android:7.3.0 from Maven Central. I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: JNI now matches the 7.3.0 AAR; iOS overlapping uploads stay independent; managed snapshot at CreateReport / native bind at Upload on both platforms; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Re-review of 586646b (prior 2506581). Both remaining Android P1s are addressed.

Closed

• ApplyTo overlays only assigned fields: Summary/Description when non-null, Email when _emailAssigned, attributes/labels when dirty. No ClearAttachments() — native/handler attachments stay. Matches iOS omit-if-untouched.
• AndroidManagedReportUploadFence: Upload captures Current; onCreated checks before apply and before upload(Report); Stop and DeleteCollectedDataOnDevice Invalidate(). GDPR wipe can no longer send a report whose create was still in openAsync.
• Prior JNI / iOS lifecycle / attachment-name / buffer-lock findings stay closed.

P0 / P1: none

Residual (not blocking): ClearAttachments() on the managed snapshot still only clears the C# list (same as iOS). Relaunch does not bump the fence (iOS relaunch also does not).

Risk: Low. Merge: Approve.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 586646b (prior 2506581). I checked the new dirty-field overlay and AndroidManagedReportUploadFence against bugsee-android 7.3.0 classes.jar (javap of Bugsee.createReport(ReportCreationListener), upload(Report), reporting.g ctor copying getUserIdentifier() / getAttributes()), against iOS createReportWithCompletion: / BugseeBridgeApplyReportDict omit-if-untouched, and against Stop/Delete callers — not the patch alone.

Addressed in this commit

• ApplyTo session wipe (P1): AndroidManagedReport now applies Email only when _emailAssigned, Summary/Description only when non-null, attributes/labels only when dirty, and no longer calls ClearAttachments(). Untouched CreateReport + Upload keeps native reporting.g email, session attributes, and handler attachments — matching iOS omitting unset keys.
• In-flight upload after Stop/Delete (P1): Stop and DeleteCollectedDataOnDevice increment AndroidManagedReportUploadFence. onCreated captures the generation at Upload and returns without ApplyTo / upload(Report) if it no longer matches. The GDPR/logout case (Upload starts openAsync, then Delete) no longer sends the session.

Prior JNI / iOS lifecycle findings stay closed: createReport(listener) at Upload, Callback1 delete, Level.fromValue + 6-arg breadcrumb, per-upload iOS ids + fence, distinct attachment name / fileName, stop-chained iOS delete, locked network buffer.

P0–P3: none remaining that I can back with a concrete failure.

---

Verdict

1. Overall risk: Low
2. Merge recommendation: Approve
3. Must-fix: none
4. What looks solid: Snapshot at CreateReport / native bind at Upload on both platforms; Android overlay now skips untouched fields the same way iOS ToResultJson omits them; Stop/Delete fence is the Android counterpart of gManagedReportUploadFence.

I inspected com.bugsee:bugsee-android:7.3.0 from Maven Central and iOS 7.0.0-beta5 Bugsee.h. I did not run WrapperPolicy tests locally (dotnet is not on PATH). GitHub Actions on 586646b is green: Wrapper policy tests, Android wrapper tests, iOS bridge tests.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 586646b (prior 2506581). I checked the new Android apply/fence commit against bugsee-android 7.3.0 classes.jar (createReport(ReportCreationListener) → createAndPrepareBugReport(Upload, null…), upload(Report) → sendBugReport, Callback1.run, Level.fromValue / 6-arg factory) and against the iOS apply-once / createReportWithCompletion path — not the patch alone.

Addressed in this commit: both remaining Android P1s.

• ApplyTo overlays only fields the snapshot actually set (Summary/Description if non-null, Email if assigned, attributes/labels if dirty). Session email (getUserIdentifier()) and getAttributes() copied by reporting.g survive a summary-only upload. ClearAttachments() is no longer called, so handler attachments added before apply are kept.
• AndroidManagedReportUploadFence is captured at Upload and checked in onCreated before apply and before upload(Report). Stop / DeleteCollectedDataOnDevice increment it, so a GDPR wipe no longer sends the in-flight session.

Prior iOS findings stay addressed: independent upload ids + gManagedReportUploadFence, apply-once at createReportWithCompletion, distinct attachment name / fileName, stop-chained delete, locked network buffer. JNI still matches the 7.3.0 AAR.

P0 / P1: none

The new iOS bind-at-upload path still drops the entire managed overlay (and still uploads) when ToResultJson() is not strict JSON.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: escape all JSON string controls (or use a real serializer) in IosReport.ToResultJson; do not uploadReport: when deserialize fails
4. Also: consider omitting labels / attachments unless the snapshot touched them (Android now does this for labels)

I inspected com.bugsee:bugsee-android:7.3.0 from Maven Central and confirmed JSON.parse / json.loads reject an unescaped tab in a string. I did not run WrapperPolicy tests (dotnet is not on PATH).

What looks solid: Android apply no longer clobbers session email/attributes; in-flight onCreated is fenced across Stop/Delete; JNI matches 7.3.0; iOS overlapping uploads stay independent; breadcrumbs fail-closed via ParseOrThrow.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Re-review of 586646b. Prior Android JNI / ApplyTo / Stop-Delete fence P1s stay closed. Independently confirmed a remaining iOS serialization hole on the new Upload(IReport) path.

P0 / P1: none

P2: IosReport.ToResultJson / IosAttachment.ToJsonObject only escape \\, ", , \r. An unescaped tab (or other U+0000–U+001F) in Summary/Description/label/attribute is not JSON. NSJSONSerialization fails, BugseeBridgeApplyReportDict is skipped, and _bugsee_upload_managed_report still calls uploadReport:. The issue lands without the text the player typed. float.NaN / Infinity via AppendValue is the same class of invalid token. Android ApplyTo sets Java strings directly and does not have this failure.

Residual: managed ClearAttachments() only clears the C# list; Relaunch does not bump the Android fence (same as iOS).

Risk: Low–Medium. Merge: Approve (P2 should-fix, not a happy-path JNI/lifecycle break).

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 586646b. The two Android P1s from 2506581 stay closed (ApplyTo overlay + AndroidManagedReportUploadFence). Independently checking the iOS bind-at-upload path against NSJSONSerialization / RFC 8259 turned up a remaining correctness hole this PR’s Upload(IReport) now depends on.

Still closed: JNI matches 7.3.0; iOS overlapping uploads; stop-chained delete; fileName vs name; locked network buffer; session email/attributes survive an untouched Android apply.

P0 / P1: none

P2: IosReport.ToResultJson() / IosAttachment.ToJsonObject() only escape \\, ", , \r. A tab (or any other U+0000–U+001F control) in Summary/Description/labels/attributes/attachment text is invalid JSON. BugseeDeserializeJson returns nil and _bugsee_upload_managed_report still calls uploadReport: — the native report goes out without the managed overlay. Android ApplyTo sets Java strings directly and does not have this failure.

---

Verdict

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Must-fix: escape all JSON string controls in AppendRawString (and the attachment helper); if deserialize fails, callback 0 and return — do not uploadReport:
4. What looks solid: Android session overlay and Stop/Delete fence; JNI; iOS upload-id independence

Confirmed: json.loads('{"summary":"Crash:\tnull ref"}') raises Invalid control character. I did not run WrapperPolicy tests locally (dotnet is not on PATH). GitHub Actions on 586646b is green.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 448da2d (merge of the report-attachment API into public-api; prior approve was b5641b2).

Prior P0–P3s from the CreateReport / delete / breadcrumb work stay closed: exclusive slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffer clear, JNI 7.3 selectors. I did not re-escalate the intentional BumpForLaunch skip-wipe.

This pass is the merge of #18 (AddAttachmentFile / path snapshots) into CreateReport. Handler apply (BugseeUnityApplyReportDict) was taught to read path + move:YES. CreateReport apply was not. PublicApiSourceTests still pins the old bytes-only BugseeBridgeApplyExtendedReportDict, so the suite cannot catch this.

Findings

1. P1 — iOS CreateReport + AddAttachmentFile uploads an empty body. IosAttachment.ToJsonObject() emits path and omits dataBase64/text; apply only reads those keys and falls back to [NSData data].
2. P2 — CreateReport never calls ReleaseSnapshotFiles(). Handler CompleteReport does (after native apply). Upload/Discard/Stop/Delete drop _openReport and leave bugsee-unity-report-attachments/* on disk.
3. P2 — Android CreateReport stores the caller path and ingests it later in async onCreated. No snapshot / File.Exists at add time. The same attach-then-delete sequence iOS snapshots for silently drops on Android.

AddAttachmentBytes still works on both platforms.

Overall risk: Medium

Merge recommendation: Request changes

Most important to fix: teach BugseeBridgeApplyExtendedReportDict to consume path (same as handler, or dataWithContentsOfFile: into the existing setAttachment: path), release snapshots on Upload completion and on Discard/Stop/Delete, and pin that in tests so CreateReport apply cannot regress to data-only. Snapshot Android CreateReport files at add time (or copy bytes) so the two platforms share one AddAttachmentFile contract.

I did not run dotnet test or device jobs in this environment (dotnet is not on PATH).

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). Independently checked BugseeBridgeApplyExtendedReportDict against IosAttachment.ToJsonObject() (path / dataBase64) and iOS 7.0.0-beta5 BugseeExtendedReport / BugseeAttachment (data-only setAttachment:). Native _bugsee_upload_managed_report applies the dict inside createReportWithCompletion: before the managed callback.

Closed at 802063a

• P1 iOS CreateReport file attachments — fully_addressed. Apply reads att[@"path"] via dataWithContentsOfFile:, skips when the read fails (no empty-NSData fallback), then attachmentWithName:filename:data: + setAttachment:. AddAttachmentBytes still uses dataBase64. Source tests pin path / dataWithContentsOfFile: on this apply.
• P2 CreateReport snapshot lifetime on Upload/Discard — fully_addressed for those paths. Upload keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion (after native apply). Discard releases immediately. Stop/Delete cancel releases in-flight upload snapshots.

Residual (not blocking)

• Stop / DeleteCollectedDataOnDevice still null _openReport without ReleaseSnapshotFiles(). CreateReport(); AddAttachmentFile(...); Stop(); (no Upload/Discard) leaves the temp snapshot until the OS reaps /tmp. Same class as the accepted #18 SetData snapshot leak.
• Delete-then-Launch skip-wipe when BumpForLaunch wins. Do not re-escalate to P1.
• BugseeAttachment has no mimeType; MIME helper remains best-effort.
• Android CreateReport still stores the caller path until onCreated (no add-time snapshot). Accepted #18 asymmetry.

Prior P0–P3s (JNI, fences, handler overlay, late Stopped, not-launched Delete buffers) still hold. Wrapper policy and Android CI green; iOS bridge still running at review time.

No remaining P0–P3. Risk Low. Merge: approve.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). I checked BugseeBridgeApplyExtendedReportDict path ingest against IosAttachment.ToJsonObject, callback ordering vs createReportWithCompletion apply, and snapshot lifetime on Upload / Discard / Stop / Delete. I did not run dotnet test (SDK not installed).

Closed at 802063a

• P1 iOS CreateReport file attachments uploading empty — fully_addressed. Apply now reads att[@"path"] with dataWithContentsOfFile:, skips when the read fails, and no longer substitutes empty NSData. AddAttachmentBytes still uses dataBase64. Native callback runs after apply, so NSData is already on the BugseeAttachment before C# releases the snapshot. PublicApiSourceTests / ReportPathSourceTests pin path + dataWithContentsOfFile:.
• P2 Upload/Discard snapshot leak — partially_addressed. DiscardReport releases immediately. UploadReport keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion. In-flight uploads are released from CancelManagedReportUpload.

Remaining

P2 Medium — Stop and both DeleteCollectedDataOnDevice branches still null _openReport without ReleaseSnapshotFiles(). An open CreateReport (attached, not yet Upload/Discard) leaks temp copies. Same drop on GDPR Delete leaves wrapper snapshots under bugsee-unity-report-attachments after native wipe.

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe. Do not re-escalate to P1.
• Android CreateReport still stores the caller path and ingests at async onCreated (no snapshot). Attach-then-delete can drop the file on Android after iOS would have kept a copy.

---

1. Overall risk: Low
2. Merge recommendation: Request changes
3. Most important to fix: _openReport?.ReleaseSnapshotFiles() on Stop and both Delete branches (same as Discard), before nulling the slot
4. Positive: CreateReport path apply matches the new JSON shape; upload snapshots survive until after native file read; failed path reads no longer attach empty bodies.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). I checked CreateReport apply against IosAttachment.ToJsonObject() path, snapshot lifetime on Upload/Discard vs Stop/Delete, and Android AddAttachmentFile (still caller-path, unchanged).

Closed in 802063a

• P1 iOS CreateReport file attachments — fully_addressed. BugseeBridgeApplyExtendedReportDict loads att[@"path"] with dataWithContentsOfFile: and skips when the read fails (no empty NSData fallback). Bytes path still uses dataBase64. Tests pin path on this apply.
• P2 Upload/Discard snapshot leak — partially_addressed. UploadReport keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion; DiscardReport releases immediately. CancelManagedReportUpload releases in-flight upload snapshots.

Prior closes stay closed: not-launched Delete buffers, late Stopped, timestamps, MIME helper, handler overlay, JNI, fences. Do not re-escalate skip-wipe to P1.

Remaining

P2 Stop/Delete still drop _openReport without ReleaseSnapshotFiles() (open CreateReport, not yet uploaded).

P2 Android CreateReport AddAttachmentFile still stores the caller path and ingests it later in onCreated (unchanged this commit).

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important to fix: _openReport?.ReleaseSnapshotFiles() on Stop and both Delete branches, matching Discard. Snapshot or copy bytes at Android AddAttachmentFile so attach-then-delete cannot drop the file.
4. Positive: Path apply plus skip-on-failed-read is the right ExtendedReport shape (setAttachment: + in-memory data). Upload completion now releases after native apply, same order as the handler path.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). I checked CreateReport apply vs handler apply, snapshot lifetime around createReportWithCompletion, and Android AndroidManagedReport.AddAttachmentFile. I did not run dotnet test (dotnet is not on PATH).

Closed

• P1 iOS CreateReport file attachments: BugseeBridgeApplyExtendedReportDict now loads att[@"path"] with dataWithContentsOfFile: before the bytes/text path, and skips the item if the file cannot be read (no empty-NSData fallback). Apply runs in the native completion before the C# callback, so the snapshot is still on disk when it is read. AddAttachmentBytes via dataBase64 still works. Source tests pin path / dataWithContentsOfFile: on this apply function.
• Upload/Discard snapshot release: UploadReport keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion; DiscardReport releases immediately.
• Prior closes still hold: not-launched Delete buffers, late Stopped, enqueue timestamps, overlay, JNI, upload fences, JSON escape/NaN. Do not re-escalate Delete(); Launch(); skip-wipe to P1.

Remaining

P2 Medium — snapshot lifetime is incomplete, and the new map is not safe for the callback thread. Details on ReleaseAllUploadSnapshotReports.

P2 Medium — Android CreateReport still stores the caller path and ingests it later in async onCreated. Details on AddAttachmentFile.

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important issues to fix: Release _openReport snapshots on Stop/Delete; serialize _uploadSnapshotReports (lock or hop the native completion onto the Unity main thread); snapshot Android CreateReport files at add time so the two platforms share one AddAttachmentFile contract.
4. Positive: The empty-upload P1 is actually fixed, unreadable paths are skipped instead of attached as zero bytes, and MIME is applied on the file path too.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). I checked BugseeBridgeApplyExtendedReportDict against ToJsonObject() path/dataBase64, upload snapshot lifetime (_uploadSnapshotReports vs HandleManagedReportCreateCompletion), Discard vs Stop/Delete, and Android AndroidManagedReport.AddAttachmentFile. Wrapper policy and Android wrapper CI jobs on this head pass; iOS bridge tests were still pending. I did not run dotnet test locally (dotnet is not on PATH).

P0 / P1: none remaining

Closed in 802063a

• P1 iOS CreateReport + AddAttachmentFile uploaded empty bytes — fully_addressed. Apply now reads att[@"path"] via dataWithContentsOfFile:, skips the row when the read fails (no empty [NSData data] fallback), and still applies dataBase64. Source tests pin path on this apply function.
• P2 Upload/Discard snapshot leak — fully_addressed for those paths. UploadReport keeps the IosReport until create completion (after native apply has copied bytes), DiscardReport releases immediately, and CancelManagedReportUpload releases in-flight upload snapshots.

Prior closes stay closed: not-launched Delete buffers, late Stopped, timestamps, handler overlay, JNI, upload fences, JSON escape/NaN. Do not re-escalate skip-wipe to P1.

Remaining

P2 Medium — Stop and both DeleteCollectedDataOnDevice branches still null _openReport without ReleaseSnapshotFiles(). Details on Stop.

P2 Medium — Android CreateReport still stores the caller path and ingests it later in async onCreated. Details on AddAttachmentFile.

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe (BumpForLaunch / ShouldRunDelete).
• IosAttachment.SetData / SetFilePath drop _path without DeleteSnapshotIfOwned() (#18 P3).
• iOS CreateReport email remains an ExtendedReport SDK gap (warning logged).

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important to fix: Release _openReport snapshots on Stop/Delete (same as Discard). Snapshot or copy Android CreateReport files at AddAttachmentFile so attach-then-delete-then-Upload matches iOS.
4. Positive: CreateReport apply now matches the #18 JSON shape, failed path reads no longer upload a zero-byte stub, and Upload waits until native apply before deleting the snapshot — the right order for dataWithContentsOfFile:.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a. Path apply and Upload/Discard snapshot lifetime stay fully_addressed. New evidence from iOS 7.0.0-beta5 Bugsee.h: createReportWithCompletion: does not run on the main thread.

Remaining

P2 — _uploadSnapshotReports is an unsynchronized Dictionary written from that off-main completion (HandleManagedReportCreateCompletion → TryGetValue/Remove) and from the Unity main thread (UploadReport insert, CancelManagedReportUpload → foreach/Clear on Stop/Delete). Concurrent mutation can throw or skip the delete. Stop/Delete still also null _openReport without ReleaseSnapshotFiles() (abandoned draft leak).

Do not re-escalate skip-wipe or Android add-time snapshot (accepted #18 residual).

Risk Medium. Merge: request changes.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Deep review — 802063a

Intent: public DeleteCollectedDataOnDevice, CreateReport / Upload / Discard, and breadcrumbs, plus iOS launch buffers.

Closed on this head

• P1 CreateReport file attachments now load path via dataWithContentsOfFile: (skip if unreadable; no empty NSData).
• Upload / Discard / in-flight cancel keep the IosReport until native apply, then ReleaseSnapshotFiles().
• Delete generation fence, breadcrumb enqueue timestamps, stale-Stopped ignore, not-launched Delete buffer clear — all still hold. Do not re-escalate the Delete(); Launch(); skip-wipe: that is the intended generation-fence tradeoff.

Remaining

• P2 Stop and both Delete branches still drop _openReport without ReleaseSnapshotFiles().
• Residual Android CreateReport stores the caller path until async onCreated (no add-time snapshot). iOS CreateReport email is warn-only. SetData / SetFilePath can abandon an owned snapshot.

I did not run the Unity / dotnet suite in this environment (dotnet is not on PATH).

Overall

1. Risk: Low
2. Merge: Approve — the empty-upload P1 is gone; leftover P2 is a temp-file leak on abandoned reports, not a broken happy-path upload.
3. Fix next: _openReport?.ReleaseSnapshotFiles() before nulling on Stop and both Delete paths.
4. Positives: path apply, upload fence, and generation/buffer work are consistent with the native 7.x contracts.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). Independently checked CreateReport apply (BugseeBridgeApplyExtendedReportDict vs IosAttachment.ToJsonObject()), snapshot lifetime on Upload/Discard/Stop/Delete, and the delete-generation fence. Native _bugsee_upload_managed_report applies the dict inside createReportWithCompletion: before the managed callback. Wrapper policy, Android wrapper, and iOS bridge CI jobs on this head pass. I did not run dotnet test locally (dotnet is not on PATH).

Closed at 802063a

• P1 iOS CreateReport file attachments — fully_addressed. Apply reads att[@"path"] via dataWithContentsOfFile:, skips when the read fails (no empty-NSData fallback), then attachmentWithName:filename:data: + setAttachment:. Bytes attachments still use dataBase64. Source tests pin path / dataWithContentsOfFile:.
• P2 Upload/Discard snapshot lifetime — fully_addressed on those paths. Upload keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion. Discard releases immediately. CancelManagedReportUpload releases in-flight snapshots.

Prior P0–P3s still hold: exclusive slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffer clear, JNI 7.3 selectors. Do not re-escalate void Delete(); Launch(); skip-wipe to P1 (fence protects the new session).

Remaining

P2 Medium — Stop and both DeleteCollectedDataOnDevice branches still drop an unused CreateReport draft without ReleaseSnapshotFiles(). See inline.

Residual (not blocking)

• Android CreateReport stores the caller path until onCreated (accepted #18 asymmetry).
• BugseeAttachment has no mimeType setter; MIME helper is best-effort.
• SetData / SetFilePath after AddAttachmentFile still drop _path without DeleteSnapshotIfOwned (#18 P3).

Overall risk: Medium
Merge: Request changes — release _openReport snapshots on Stop/Delete (especially GDPR Delete).
Most important to fix: Stop / DeleteCollectedDataOnDevice must call ReleaseSnapshotFiles() before nulling the unused draft.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 802063a (prior 448da2d). I checked CreateReport apply against IosAttachment.ToJsonObject() (path / dataBase64), snapshot lifetime on Upload / Discard vs Stop / Delete, and Android AndroidManagedReport.AddAttachmentFile. Wrapper policy, Android wrapper, and iOS bridge CI jobs are green on this head.

Closed at 802063a

• P1 iOS CreateReport file attachments uploading empty — fully_addressed. BugseeBridgeApplyExtendedReportDict now reads att[@"path"] with dataWithContentsOfFile:, skips when the read fails (no empty-NSData fallback), then attachmentWithName:filename:data: + setAttachment:. Native apply runs inside createReportWithCompletion: before the managed callback, so the snapshot is still on disk when it is read. Bytes attachments still use dataBase64. Source tests pin path / dataWithContentsOfFile: on this apply.
• P2 Upload / Discard snapshot release — partially_addressed. UploadReport keeps the IosReport in _uploadSnapshotReports until HandleManagedReportCreateCompletion. DiscardReport releases immediately. CancelManagedReportUpload releases in-flight upload snapshots only.

Prior closes still hold: exclusive CreateReport slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffer clear, JNI 7.3 selectors, handler path apply. Do not re-escalate void Delete(); Launch(); skip-wipe to P1.

Remaining

Two P2s, both with concrete failure paths. Details on the inline comments.

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important to fix: _openReport?.ReleaseSnapshotFiles() on Stop and both Delete branches before nulling the slot (GDPR Delete must not leave wrapper temp copies). Snapshot or copy bytes at Android AddAttachmentFile so attach-then-delete-then-Upload matches iOS.
4. Positive: Path apply now matches the #18 JSON shape; failed reads no longer attach a zero-byte stub; Upload waits until after native file ingest before releasing snapshots.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). I checked iOS Stop/Delete draft release, _uploadSnapshotReports locking, and Android AddAttachmentFile snapshot-at-add vs upload/cancel lifetime. I did not run dotnet test (dotnet is not on PATH).

Closed at 17aae36

• P2 iOS Stop/Delete dropping an open CreateReport without ReleaseSnapshotFiles() — fully_addressed. All three paths release the draft before nulling. Tests pin Stop and Delete.
• P2 unsynchronized _uploadSnapshotReports — fully_addressed. Insert/remove/clear run under _uploadSnapshotReportsGate; file delete on the per-token path is after the lock.
• P2 Android CreateReport storing the caller path until onCreated — partially_addressed. AddAttachmentFile now File.Exists + SnapshotAttachmentFile + SetSnapshotPath, so attach-then-delete-then-Upload keeps the copy. Stop/Delete/Discard/ClearAttachments release those copies.

Prior closes still hold: iOS CreateReport path apply, Upload/Discard snapshot order, exclusive slot, fences, overlay, JSON escape/NaN, late Stopped, enqueue timestamps, not-launched Delete buffers, JNI. Do not re-escalate Delete(); Launch(); skip-wipe to P1.

Remaining

P2 Medium — Android CreateReport snapshots are never released after Upload (or after a fenced-off onCreated). Details on the listener.

---

1. Overall risk: Low
2. Merge recommendation: Request changes
3. Most important to fix: try/finally ReleaseSnapshotFiles() in onCreated after ApplyTo (and on the early fence/null returns). Stop/Delete after Upload() currently cannot see the proxy-owned snapshot, so GDPR cancel of an in-flight create leaves the new temp copies.
4. Positive: iOS abandoned-draft leak and Dictionary race are actually gone; Android attach-then-delete now matches iOS at add time.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). I checked iOS Stop/Delete snapshot release, the _uploadSnapshotReports lock, and the new Android AddAttachmentFile snapshot. I did not run dotnet test (SDK not installed).

Closed at 17aae36

• P2 iOS Stop/Delete dropping _openReport without ReleaseSnapshotFiles() — fully_addressed. All three branches release before nulling. Source tests pin Stop and Delete.
• P2 Android CreateReport storing the caller path until onCreated — fully_addressed for attach-then-delete. AddAttachmentFile now File.Exists + SnapshotAttachmentFile + SetSnapshotPath. Stop/Delete/Discard release Android snapshots. SetFilePath / SetSnapshotPath delete a previous owned copy.
• P2 unsynchronized _uploadSnapshotReports — fully_addressed. Insert, per-token release, and ReleaseAll take _uploadSnapshotReportsGate.

P1 path apply from 802063a still holds. Prior closes (buffers, late Stopped, timestamps, overlay, JNI, fences, JSON) still hold. Do not re-escalate skip-wipe to P1.

Remaining

P2 Medium — Android Upload never releases the new snapshots. UploadReport moves the managed report into ReportCreationListenerProxy and nulls _openReport. onCreated calls ApplyTo (addAttachment(File, …, false) copies; it does not move) and never ReleaseSnapshotFiles(). Early fence/null returns and the catch path also skip release. Stop/Delete cannot recover it: _openReport is already null, and there is no in-flight map like iOS _uploadSnapshotReports.

Happy-path CreateReport + AddAttachmentFile + Upload on Android leaves bugsee-unity-report-attachments/<guid> on disk. Upload then Stop before onCreated is the same leak if the listener never runs.

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe.
• SetData on a file snapshot still drops _path without DeleteSnapshotIfOwned (iOS and Android).

---

1. Overall risk: Low
2. Merge recommendation: Request changes
3. Most important to fix: ReleaseSnapshotFiles() after native ingest in onCreated (including early/error paths), and keep the in-flight managed report so Stop/Delete can release if the listener never runs — same shape as iOS Upload completion.
4. Positive: iOS abandoned-draft and Android add-time snapshot now match; the dictionary lock is the right fix for the off-main create completion.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). I checked iOS Stop/Delete/_uploadSnapshotReportsGate, Android AndroidManagedReport.AddAttachmentFile snapshotting, and whether Upload/onCreated releases those copies. Wrapper policy and Android wrapper CI jobs on this head pass; iOS bridge tests were still pending. I did not run dotnet test locally (dotnet is not on PATH).

P0 / P1: none remaining

Closed in 17aae36

• P2 iOS Stop / both Delete branches dropping _openReport without ReleaseSnapshotFiles() — fully_addressed. Same helper as Discard; source test pins Stop and Delete.
• P2 _uploadSnapshotReports unsynchronized vs off-main completion — fully_addressed. Mutations go through _uploadSnapshotReportsGate; file delete in ReleaseUploadSnapshotReport is outside the lock.
• P2 Android CreateReport attach-then-delete drop — fully_addressed as a missing-file bug. AddAttachmentFile now File.Exists + SnapshotAttachmentFile + SetSnapshotPath, matching iOS add-time copy.

Prior closes stay closed: CreateReport path apply, iOS Upload/Discard snapshot lifetime, not-launched Delete buffers, late Stopped, timestamps, handler overlay, JNI, fences, JSON escape/NaN. Do not re-escalate skip-wipe to P1.

Remaining

P2 Medium — Android snapshots are never released on the Upload / in-flight-create path. Details on onCreated.

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe (BumpForLaunch / ShouldRunDelete).
• SetData on iOS IosAttachment and Android AndroidManagedAttachment still drop _path without DeleteSnapshotIfOwned() (#18 P3; Android SetFilePath/SetSnapshotPath now do delete).
• iOS CreateReport email remains an ExtendedReport SDK gap (warning logged).

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important to fix: ReleaseSnapshotFiles() in onCreated (try/finally), including fence/null early returns; keep the in-flight Android snapshot on the bridge so Stop/Delete can release if the listener never runs.
4. Positive: Abandoned iOS/Android drafts now release on Stop/Delete/Discard; Android attach-then-delete-then-Upload now has a copy at add time; the iOS completion map is locked.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). Independently checked iOS Stop/Delete release, _uploadSnapshotReports locking, and the new Android add-time snapshot.

Closed at 17aae36

• P2 iOS _uploadSnapshotReports race — fully_addressed. Insert / ReleaseAll / ReleaseUpload take _uploadSnapshotReportsGate; file delete runs after the lock.
• P2 iOS Stop / both Delete branches — fully_addressed. _openReport?.ReleaseSnapshotFiles() before nulling. Source test pins Stop and Delete.
• Android AddAttachmentFile now snapshots at add (File.Exists + SnapshotAttachmentFile + SetSnapshotPath). Stop / Delete / Discard release those copies. SetFilePath / SetSnapshotPath call DeleteSnapshotIfOwned.

Remaining

P2 Android CreateReport upload never releases the new snapshots. UploadReport hands the AndroidManagedReport to ReportCreationListenerProxy and nulls _openReport. onCreated ApplyTos (native addAttachment(File, …, false) copies) then uploads, with no ReleaseSnapshotFiles(). Early fence/null returns also drop the snapshot. Stop after Upload cannot clean up — the slot is already empty.

Same hole iOS closed with _uploadSnapshotReports until after native apply.

Do not re-escalate skip-wipe. SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (accepted #18 P3).

Risk Medium. Merge: request changes.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). I checked Stop/Delete snapshot release on iOS and Android, Android AddAttachmentFile snapshotting, _uploadSnapshotReports locking, and Android upload completion (ReportCreationListenerProxy.onCreated). 7.x Report.addAttachment(File, name, mime, move) copies when move is false (this wrapper passes false).

Closed at 17aae36

• P2 iOS Stop / both Delete branches dropping _openReport without ReleaseSnapshotFiles() — fully_addressed. Same helper as Discard, before nulling the slot. Source tests pin Stop and Delete.
• P2 Android CreateReport AddAttachmentFile storing the caller path — fully_addressed at add time. File.Exists, copy to bugsee-unity-report-attachments, SetSnapshotPath. Stop / Delete / Discard now release those copies. _uploadSnapshotReports mutations are locked.

Prior closes still hold: path apply, exclusive slot, fences, overlay, JSON escape/NaN, late Stopped, breadcrumb timestamps, not-launched Delete buffers, JNI 7.3 selectors. Do not re-escalate skip-wipe to P1.

Remaining

One P2, introduced by adding Android snapshots without a release-after-ingest path. Details on the inline comment.

---

1. Overall risk: Medium
2. Merge recommendation: Request changes
3. Most important to fix: ReleaseSnapshotFiles() in onCreated (including fence-fail / null-report / exception paths) after ApplyTo, matching iOS HandleManagedReportCreateCompletion.
4. Positive: Abandoned-draft leak on Stop/Delete is gone on both platforms; Android attach-then-delete now matches iOS; iOS upload-map locking matches the off-main createReportWithCompletion contract.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). Independently checked iOS Stop/Delete _openReport release, the _uploadSnapshotReports lock, and Android AddAttachmentFile snapshot-at-add vs ReportCreationListenerProxy.onCreated. I did not run dotnet test locally (dotnet is not on PATH).

Closed at 17aae36

• P2 iOS Stop / both Delete branches dropping an unused CreateReport draft — fully_addressed. All three paths call _openReport?.ReleaseSnapshotFiles() before nulling. ReportPathSourceTests pins Stop and Delete. Android Stop/Delete/Discard do the same for the open slot.
• P2 Android CreateReport AddAttachmentFile storing the caller path — fully_addressed for attach-then-delete-original. Managed reports now File.Exists, SnapshotAttachmentFile, and SetSnapshotPath (same contract as iOS).
• P2 unsynchronized _uploadSnapshotReports — fully_addressed. Insert / TryGetValue-Remove / foreach-Clear all take _uploadSnapshotReportsGate. File deletes run outside the per-token lock.

Prior P0–P3s still hold: CreateReport path apply, iOS Upload/Discard snapshot lifetime, exclusive slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb timestamps, not-launched Delete buffers, JNI 7.3. Do not re-escalate void Delete(); Launch(); skip-wipe.

Remaining

P2 Medium — Android now owns temp copies, but onCreated never calls ReleaseSnapshotFiles(). See inline. iOS Upload already releases from HandleManagedReportCreateCompletion / CancelManagedReportUpload; Android has no equivalent for the proxy-held snapshot (UploadReport nulls _openReport before createReport).

Residual (not blocking)

• SetData / SetFilePath after AddAttachmentFile can still drop _path without deleting an owned snapshot on iOS; Android SetFilePath now deletes first, SetData still does not.
• MIME helper remains best-effort on beta5 BugseeAttachment.
• Skip-wipe when BumpForLaunch wins.

Overall risk: Medium
Merge: Request changes — try/finally _snapshot.ReleaseSnapshotFiles() in onCreated (including fence-cancel and null-report returns).
Most important to fix: Release Android CreateReport snapshots after native ingest or when the upload is cancelled, matching iOS.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of 17aae36 (prior 802063a). Independently checked Stop/Delete/Discard snapshot release on both bridges, Android AddAttachmentFile snapshot-at-add, ReportCreationListenerProxy.onCreated, and the iOS _uploadSnapshotReports lock. I did not run dotnet test locally (dotnet is not on PATH).

Closed at 17aae36

• P2 unused CreateReport draft snapshots on Stop / DeleteCollectedDataOnDevice — fully_addressed. iOS Stop and both Delete branches call _openReport?.ReleaseSnapshotFiles() before nulling the slot. Android Stop, Delete, and Discard do the same. Source tests pin the iOS Stop/Delete calls.
• P2 Android AddAttachmentFile storing the caller path — partially_addressed. Managed AddAttachmentFile now File.Exists, copies to bugsee-unity-report-attachments, and SetSnapshotPath. Attach-then-delete-then-Upload no longer depends on the original file still existing at onCreated.
• iOS _uploadSnapshotReports mutations are now under _uploadSnapshotReportsGate.

Prior closes still hold: CreateReport path apply, iOS Upload/Discard snapshot lifetime, exclusive slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffer clear, JNI 7.3 selectors. Do not re-escalate void Delete(); Launch(); skip-wipe to P1.

Remaining

P2 Medium — Android Upload never releases the new owned snapshots. UploadReport moves the report off _openReport into ReportCreationListenerProxy; onCreated ApplyTos then returns with no ReleaseSnapshotFiles(). Stop/Delete only release the unused draft (_openReport), so an in-flight or completed Upload leaks the copies this commit just started owning. See inline.

Residual (not blocking)

• IAttachment.SetData / iOS SetFilePath still drop _path without DeleteSnapshotIfOwned (#18 P3). Android SetFilePath now deletes.
• BugseeAttachment has no mimeType setter; MIME helper is best-effort.

Overall risk: Medium
Merge: Request changes — Android must release upload snapshots the way iOS already does after native apply.
Most important to fix: finally { _snapshot.ReleaseSnapshotFiles(); } in onCreated (including fence-invalid / null-report returns), matching iOS HandleManagedReportCreateCompletion.

Positive: Unused-draft GDPR wipe on Stop/Delete now matches Discard on both platforms; Android attach-then-delete works at add time; iOS dictionary access is locked.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Overall risk: Medium. Merge: request changes.

17aae36 closes the two P2s from 802063a: iOS/Android Stop and Delete now call ReleaseSnapshotFiles() before dropping _openReport, and Android CreateReport snapshots files at add time (File.Exists + copy + SetSnapshotPath). iOS still holds in-flight upload snapshots in _uploadSnapshotReports (now locked) until native create completes.

The new Android snapshot copies are not released after Upload (or after a fenced-off onCreated). That is the remaining P2.

Most important to fix

1. P2 — Android CreateReport file snapshots leak after Upload / cancelled onCreated. Release in ReportCreationListenerProxy.onCreated (all exits), after ApplyTo so the native addAttachment(..., false) copy has finished.

Residual (not blocking this round)

• Sequential DeleteCollectedDataOnDevice(); Launch(); still skips the in-flight wipe via BumpForLaunch / ShouldRunDelete. Do not re-escalate to P1.
• IosAttachment.SetData / SetFilePath still drop _path without DeleteSnapshotIfOwned() (same hole as #18).
• MIME on beta5 BugseeAttachment remains best-effort.

Positive

JNI matches Android 7.3 (createReport(listener), Callback1, fromValue + 6-arg breadcrumb). Overlay-vs-replace, JSON escape/NaN, exclusive CreateReport slot, upload fence, late Stopped, breadcrumb enqueue timestamps, and iOS path apply all still look correct. CI on this head (run 37963089037): Wrapper policy, Android wrapper, and iOS bridge pass. I did not run dotnet test locally (dotnet is not on this runner).

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). Independently checked ReportCreationListenerProxy.onCreated: fence/null early returns, ApplyTo, and upload all sit in try, with _snapshot.ReleaseSnapshotFiles() in finally after ApplyTo. Native addAttachment(File, …, false) has already copied. Source test pins ReleaseSnapshotFiles() after ApplyTo.

Closed at b8b2fd3

• P2 Android CreateReport upload snapshot leak — fully_addressed. Success, fence-cancel, null report, and exceptions all release. Matches iOS HandleManagedReportCreateCompletion order.

Prior closes still hold: iOS path apply, iOS Upload/Discard/Stop/Delete release, _uploadSnapshotReports lock, Android add-time snapshot, JNI, fences, overlay, JSON, late Stopped, not-launched Delete buffers.

Residual (not blocking)

• If createReport never invokes onCreated, the proxy-held snapshot is not released (Stop/Delete already nulled _openReport). Same class as a lost listener, not the happy path.
• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (#18 P3).
• Delete-then-Launch skip-wipe. Do not re-escalate to P1.
• CreateReport MIME helper remains best-effort on beta5 BugseeAttachment.

Wrapper policy CI green; Android/iOS still running at review time.

No remaining P0–P3. Risk Low. Merge: approve.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). I checked ReportCreationListenerProxy.onCreated against ApplyTo (addAttachment(File, …, false) copies) and iOS HandleManagedReportCreateCompletion ordering. I did not run dotnet test (SDK not installed).

P0 / P1 / P2: none remaining

Closed at b8b2fd3

• P2 Android Upload never releasing CreateReport snapshots — fully_addressed. onCreated wraps fence checks, null report, ApplyTo, and upload in try/finally and always _snapshot?.ReleaseSnapshotFiles(). Success path still ApplyTos before the finally (native copy finishes first). Fence-invalid and null-report exits also delete. ReportPathSourceTests pins ReleaseSnapshotFiles after ApplyTo.

Closed earlier (still holds)

• iOS CreateReport path apply (dataWithContentsOfFile:, skip on failed read).
• iOS Upload/Discard snapshot lifetime and _uploadSnapshotReports lock.
• iOS/Android Stop/Delete/Discard _openReport?.ReleaseSnapshotFiles().
• Android add-time File.Exists + snapshot copy.
• Exclusive slot, fences, overlay, JSON escape/NaN, late Stopped, breadcrumb timestamps, not-launched Delete buffers, JNI 7.3 selectors.

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe (BumpForLaunch / ShouldRunDelete). Do not re-escalate to P1.
• If Android onCreated is never invoked after Stop, the proxy-held snapshot would still leak (no in-flight map like iOS). The SDK still typically delivers the listener; finally covers that delivery. Not merge-blocking.
• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (iOS and Android).

---

1. Overall risk: Low
2. Merge recommendation: Approve
3. Most important issues to fix: none remaining on this head
4. Positive: Android Upload now matches iOS (native ingest, then delete the owned copy) including cancelled/failed create. Abandoned drafts and add-time snapshots were already in place from 17aae36.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). I checked ReportCreationListenerProxy.onCreated against ApplyTo / addAttachment(File, …, false) and the iOS HandleManagedReportCreateCompletion order. I did not run dotnet test (dotnet is not on PATH).

Closed at b8b2fd3

• P2 Android CreateReport snapshots never released after Upload / cancelled onCreated — fully_addressed. The whole listener is in try/finally; fence-inactive, null report, ApplyTo, upload, and exceptions all call _snapshot.ReleaseSnapshotFiles(). Release runs after ApplyTo, so the JNI copy (move=false) has finished. Source test pins ReleaseSnapshotFiles() after ApplyTo.

Prior closes still hold: iOS CreateReport path apply, Upload/Discard/Stop/Delete snapshot lifetime, _uploadSnapshotReports lock, Android snapshot-at-add, exclusive slot, fences, overlay, JSON escape/NaN, late Stopped, enqueue timestamps, not-launched Delete buffers, JNI 7.3 selectors. Do not re-escalate Delete(); Launch(); skip-wipe to P1.

Residual (not blocking)

• If native never invokes onCreated after Upload, the proxy-owned snapshot has no other owner (unlike iOS _uploadSnapshotReports + CancelManagedReportUpload). 7.3 createReport(listener) is documented to call onCreated (including null). Not a happy-path leak.
• SetData after AddAttachmentFile can still drop _path without DeleteSnapshotIfOwned (accepted #18 P3).
• MIME helper remains best-effort on beta5 BugseeAttachment.

---

1. Overall risk: Low
2. Merge recommendation: Approve
3. Most important issues to fix: none remaining at P0–P2
4. Positive: CreateReport file attachments now round-trip on both platforms (iOS path → dataWithContentsOfFile:, Android add-time copy → JNI ingest → finally release), and abandoned drafts release on Stop/Delete/Discard.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). I checked ReportCreationListenerProxy.onCreated against ApplyTo / addAttachment(..., false) and the new Android_upload_releases_snapshots_after_onCreated pin. Wrapper policy CI on this head pass; Android wrapper and iOS bridge tests were still pending. I did not run dotnet test locally (dotnet is not on PATH).

P0 / P1 / P2: none remaining

Closed in b8b2fd3

• P2 Android CreateReport snapshots never released after Upload / cancelled onCreated — fully_addressed. Fence-invalid, null report, ApplyTo/upload, and exceptions all hit finally { _snapshot?.ReleaseSnapshotFiles(); }. Release is after ApplyTo, so native has already copied (move=false). Source test pins ReleaseSnapshotFiles after ApplyTo.

Still closed

• iOS CreateReport path apply (dataWithContentsOfFile:, skip on failed read).
• iOS Upload/Discard snapshot lifetime; Stop/Delete draft release; _uploadSnapshotReports lock.
• Android add-time snapshot (File.Exists + copy + SetSnapshotPath); Stop/Delete/Discard release the open slot.
• Exclusive slot, fences, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb timestamps, not-launched Delete buffers, JNI 7.3 selectors.
• Do not re-escalate void Delete(); Launch(); skip-wipe (BumpForLaunch / ShouldRunDelete) to P1.

Residual (not blocking)

• If native never invokes onCreated after Stop (listener dropped), the proxy-held copy would remain. 7.x createReport(listener) is specified to call back; fence-cancel now releases when it does.
• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (iOS + Android; accepted #18 P3). Android SetFilePath / SetSnapshotPath now delete.
• iOS CreateReport email remains an ExtendedReport SDK gap (warning logged). MIME helper on beta5 BugseeAttachment is best-effort.

---

1. Overall risk: Low
2. Merge recommendation: Approve
3. Most important to fix: none remaining on this head
4. Positive: CreateReport file attachments now snapshot at add on both platforms, apply from path/File at upload, and release owned copies on Upload, Discard, Stop, Delete, and cancelled Android create.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). Independently checked ReportCreationListenerProxy.onCreated: fence/null paths now sit inside try, ApplyTo still runs before ReleaseSnapshotFiles(), and finally covers success, fence-cancel, null report, and exceptions. Wrapper policy and Android wrapper CI jobs on this head pass; iOS bridge was still running at review time. I did not run dotnet test locally (dotnet is not on PATH).

Closed at b8b2fd3

• P2 Android CreateReport snapshots never released on Upload — fully_addressed. onCreated try/finally calls _snapshot.ReleaseSnapshotFiles() on every exit, after native addAttachment(..., false) has copied. Android_upload_releases_snapshots_after_onCreated pins ApplyTo before release. Fence-invalid and null-report returns no longer skip cleanup.

Closed earlier (still holds)

• iOS Stop/Delete unused-draft release; iOS Upload/Discard snapshot lifetime; _uploadSnapshotReportsGate; Android snapshot-at-add; CreateReport path apply; exclusive slot; upload fence; overlay-vs-replace; JSON escape/NaN; late Stopped; breadcrumb timestamps; not-launched Delete buffers; JNI 7.3 selectors.

Do not re-escalate void Delete(); Launch(); skip-wipe to P1.

Residual (not blocking)

• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (iOS; Android SetFilePath now deletes first).
• MIME helper remains best-effort on beta5 BugseeAttachment.
• If native createReport never invokes onCreated, the proxy-held snapshot would still leak (no finalizer). The 7.3 listener contract is to call onCreated including on failure; not treated as a remaining defect.

P0 / P1 / P2: none remaining

Overall risk: Low
Merge: Approve
Most important to fix: none for this head
Positive: Wrapper-owned file copies now have a release path on Discard, Stop, Delete, iOS Upload completion, and Android onCreated, including GDPR cancel of an in-flight create.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). I checked ReportCreationListenerProxy.onCreated against AndroidManagedReport.ReleaseSnapshotFiles, the 7.x addAttachment(File, …, move=false) copy contract, and Android_upload_releases_snapshots_after_onCreated.

Closed at b8b2fd3

• P2 Android CreateReport snapshots never released on Upload / cancelled onCreated — fully_addressed. The whole listener is in try/finally; fence-invalid, null report, ApplyTo+upload, and exceptions all call _snapshot.ReleaseSnapshotFiles(). ApplyTo still runs first on the success path, so native has copied before the wrapper temp is deleted. Source test pins ReleaseSnapshotFiles after ApplyTo.

Closed earlier (still holds)

• iOS CreateReport path apply (dataWithContentsOfFile:, skip on failed read)
• iOS Upload/Discard snapshot lifetime + _uploadSnapshotReports lock
• iOS/Android Stop and Delete release unused drafts
• Android AddAttachmentFile snapshots at add (File.Exists + copy + SetSnapshotPath)
• Exclusive CreateReport slot, upload fences, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffers, JNI 7.3 selectors

Residual (not blocking)

• Void Delete(); Launch(); skip-wipe when BumpForLaunch wins. Do not re-escalate to P1.
• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (iOS; Android SetFilePath/SetSnapshotPath now delete).
• MIME helper remains best-effort on beta5 BugseeAttachment.
• If native never invokes onCreated at all after Stop, the proxy is the only owner — same class as needing a bridge-side in-flight map. Not treating as P2 without evidence the SDK drops the listener.

No remaining P0–P3.

---

1. Overall risk: Low
2. Merge recommendation: Approve
3. Most important issues to fix: None for this head.
4. Positive: Android upload now matches iOS — native ingest first, then delete the owned snapshot, including cancel/error exits.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Stale comment

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). Independently checked ReportCreationListenerProxy.onCreated: fence/null/ApplyTo/upload all sit inside try, and finally always calls _snapshot.ReleaseSnapshotFiles(). Native ingest (ApplyTo → addAttachment(File, …, false)) still runs before that delete. Source test pins ApplyTo then ReleaseSnapshotFiles(). I did not run dotnet test locally (dotnet is not on PATH).

Closed at b8b2fd3

• P2 Android Upload never releasing owned snapshots — fully_addressed. onCreated releases on success, fence-invalid, null report, and exception. Stop/Delete during in-flight createReport still get a delete when the listener runs (fence check returns, finally still runs). iOS already released from HandleManagedReportCreateCompletion / CancelManagedReportUpload.

Closed at 17aae36 and still holding: unused-draft Stop/Delete release on both platforms, Android snapshot-at-add, _uploadSnapshotReportsGate.

Prior closes still hold: CreateReport path apply, iOS Upload/Discard snapshot lifetime, exclusive slot, upload fence, overlay-vs-replace, JSON escape/NaN, late Stopped, breadcrumb enqueue timestamps, not-launched Delete buffer clear, JNI 7.3 selectors. Do not re-escalate void Delete(); Launch(); skip-wipe to P1.

Remaining

No remaining P0–P3.

Residual (not blocking)

• SetData after AddAttachmentFile still drops _path without DeleteSnapshotIfOwned (iOS SetFilePath too; Android SetFilePath now deletes). Same #18 P3.
• MIME helper remains best-effort on beta5 BugseeAttachment.
• If onCreated never runs, wrapper temps wait until the OS reaps cache. The 7.3 listener is documented to fire (including null on failure); Stop/Delete do not hold an in-flight Android map the way iOS _uploadSnapshotReports does. Not a must-fix given that contract.

Overall risk: Low
Merge: Approve
Most important to fix: Nothing remaining for this PR.
Positive: finally covers every onCreated exit without deleting before native copy; attach-then-delete-then-Upload now matches iOS on both add and cleanup.

  

_{Sent by Cursor Automation: Bugsee code review}

[cursor]

Review: Add delete-data, create-report, and breadcrumbs

Re-review of b8b2fd3 (prior 17aae36). I checked ReportCreationListenerProxy.onCreated against ApplyTo (addAttachment(File, …, false) copies into the native report) and the iOS HandleManagedReportCreateCompletion / _bugsee_complete_report ordering. WrapperPolicy CI on this head is green (37964082103). I did not run dotnet test locally (dotnet is not on PATH).

Closed at b8b2fd3

• P2 Android Upload / onCreated never ReleaseSnapshotFiles() — fully_addressed. Fence / null / ApplyTo / upload all sit in try; finally always releases. That covers the happy path, fence-cancel, null report, and exceptions. ApplyTo still runs before delete, so the 7.3 copy (move=false) has already ingested the file. Android_upload_releases_snapshots_after_onCreated pins the order.

Closed earlier (still holds)

iOS/Android Stop and Delete release unused drafts; Android snapshots at add; _uploadSnapshotReports is locked; CreateReport path apply; exclusive slot; upload fences; attribute overlay; JSON control/NaN handling; late lifecycle Stopped; breadcrumb enqueue timestamps; not-launched Delete clears buffers; JNI 7.3 selectors.

Residual (not blocking)

• Delete(); Launch(); still skip-wipe via BumpForLaunch / ShouldRunDelete so the new session is not deleted. Do not re-escalate to P1.
• IAttachment.SetData after AddAttachmentFile still nulls _path without DeleteSnapshotIfOwned (iOS and Android). Upload then cannot delete the owned temp copy. Same leftover as #18.

P0 / P1 / P2: none remaining.

1. Overall risk: Low
2. Merge recommendation: approve
3. Most important issues to fix: none for merge. Optional follow-up: call DeleteSnapshotIfOwned() in SetData before dropping _path.
4. Positives: CreateReport, DeleteCollectedData, and breadcrumbs now match 7.x listeners/selectors; iOS buffers network + breadcrumbs until launch; managed uploads overlay instead of clobbering session attributes; snapshot lifetime is finally closed on the Android upload path.

  

_{Sent by Cursor Automation: Bugsee code review}