fix: skip screenshot capture in batch mode

[bobbyg603]

Closes #164

Problem

DotNetStandardExceptionReporter.Post yields new WaitForEndOfFrame() before capturing the screenshot. On a dedicated server or any -batchmode run there is no render loop, so that yield never resumes. The coroutine stops right there, before exceptionClient.Post is ever reached, so the report is never uploaded and the callback never fires. This is silent data loss, not just a missing screenshot.

Fix

Skip the capture entirely when Application.isBatchMode, and log why. Everything downstream (attachments, upload, callback) runs as normal.

The check goes through an internal Func<bool> isBatchMode seam (same pattern as the existing reportUploadGuardService seam) so the branch is deterministically reachable from a test whether or not the test runner itself is batched. It is declared next to the screenshot helper instead of with the other fields to keep the whole change inside the screenshot block — two other fixes (#160, #163) are in flight on this file and this keeps the three diffs disjoint.

Editor variant: intentionally out of scope

The same wedge can happen in the editor when the Game view is not rendering (hidden/undocked Game view, editor test runs without a Game view). It is not addressed here, deliberately rather than by oversight:

• Application.isBatchMode already covers the editor when it is launched with -batchmode (including this repo's CI test runner), so the CI path is safe.
• Catching the remaining editor cases needs either editor-only APIs to ask whether the Game view is actually rendering, or a watchdog that races WaitForEndOfFrame against a frame/time budget. Both restructure the coroutine well beyond the scope of this fix, and a watchdog is the more honest general answer since it would also cover headless-graphics players.

Flagging it explicitly because a hung report coroutine is silent data loss: the editor case is developer-facing and transient, whereas the batch-mode case affects shipped dedicated servers, which is why only the latter is fixed here.

Test

Post_WhenCaptureScreenshotsAndBatchMode_ShouldPostWithoutScreenshot in Tests/Runtime/Reporter/DotNetStandardExceptionReporterTests.cs sets CaptureScreenshots = true with the batch-mode seam forced true and asserts that the report still reaches the client with no screenshot form-data param. Without the fix, that test hangs on WaitForEndOfFrame in any non-rendering runner instead of reaching the assertions.

Verification

Compiled Runtime/** + Tests/Runtime/** against the Unity 6000.5.6f1 managed assemblies with dotnet build: build succeeded, 0 errors, 2 pre-existing unrelated CS0649 warnings in Runtime/BugSplat.cs. The new [UnityTest] was not executed — running it requires the Unity test runner, which is not available in this environment; it will run in the Tests workflow on this PR.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR prevents BugSplat exception uploads from silently wedging in Unity -batchmode / dedicated-server scenarios by skipping screenshot capture (which previously yielded WaitForEndOfFrame() and could never resume without a render loop), ensuring the upload and callback still complete.

Changes:

• Skip screenshot capture when Application.isBatchMode (via an internal isBatchMode seam) to avoid hanging the report coroutine.
• Add a runtime UnityTest to ensure posting proceeds without adding a screenshot form-data parameter when batch mode is forced on.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
Runtime/Reporter/DotNetStandardExceptionReporter.cs	Skips WaitForEndOfFrame screenshot capture in batch mode so the report upload still runs.
Tests/Runtime/Reporter/DotNetStandardExceptionReporterTests.cs	Adds a UnityTest covering the batch-mode + CaptureScreenshots path to ensure the post completes without screenshot form-data.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.