[bitsandfoxes]

The iOS Crash Capture integration test now ignores App Hang events when it looks up the crash event by its test.crash_id tag.

The test app enables app-hang tracking with a 2 s timeout. That applies to every scenario, so a crash run can produce a hang too. On a slow simulator, sentry-cocoa reports an App Hang Non Fully Blocked event (mechanism.type = AppHang, level error) about a second before the forced crash. By then the crash tag is already on the scope, so Sentry ends up with two events for the tag. The lookup expects exactly one: it polls for the full 300 s and fails with "Expected 1, but got 2", and the job has to be rerun on macOS. In the last 30 days, Sentry received 15 of these hang events tagged with a crash ID, all from iOS. This was the most common test flake in the CI analysis: 13 failed Run iOS jobs in the window that still has logs.

How it works:

• Get-SentryTestEvent in app-runner takes a -Filter scriptblock (feat: Add Filter parameter to Get-SentryTestEvent app-runner#63). The filter runs on the tag lookup's results before the count check.
• Crash Capture passes a filter that drops events whose first exception has mechanism.type AppHang. It reads the fields through Get-EventProperty/Get-EventList, so an event without an exception doesn't break the lookup under StrictMode. That event passes the filter and still counts.
• Get-EventProperty reads dictionary keys now. The Sentry API client parses responses with ConvertFrom-Json -AsHashtable, so everything below the top level of an event is a hashtable, and PSObject.Properties doesn't list hashtable keys. Without this, the filter would have read $null for every event and dropped nothing. It also fixes Write-EventDiagnostics, which has always reported "no exception stack trace frames" for the same reason.
• The count check stays at exactly one. Two crash events still fail the test. "At least one, take the first" would sometimes have picked the hang event, because results come back unordered.

The modules/app-runner bump goes from 63d8c36 to the app-runner commit above. It also pulls in 24 commits from app-runner main: SauceLabs retries, device power reporting, no-op provider commands, and new Sentry API helpers for attachments, spans, replays and feedback. The power-reporting and no-op changes (getsentry/app-runner#60, #61) go through the command path that Connect-Device, Install-DeviceApp, Invoke-DeviceApp and Disconnect-Device use for every provider, so this PR's CI run is also the check for those.

App-hang tracking stays on during the crash scenario. The App Hang tests only run on Desktop and Android, where the in-proc watchdog is driven by the C# heartbeat, and they need the 2 s timeout (the app blocks the main thread for 5 s). On Android the NDK app-hang settings get written into the manifest at build time, so turning tracking off for one action at runtime wouldn't apply evenly across platforms. Running the crash with hang tracking on also matches how users run the SDK.

CI:

• Green run on this branch (run): all 56 jobs passed. No hang landed inside the crash scenario there, so the filter had nothing to drop.
• Hang forced on purpose, in a commit dropped before review (run): on iOS only, the crash scenario blocked the main thread for 3 s before crashing. For each crash ID, Sentry received two events: the fatal Utils_CUSTOM_ForceCrash, and App Hang Fully Blocked (mechanism: AppHang) 1–2 s before it, both tagged with the crash ID. All four Run iOS jobs passed, 57/57 each. Without the filter, that pair is the "Expected 1, but got 2" failure. The run's one red job was an unrelated editor kill in Build Linux 6000.6 (Killed during assembly reload, in "Add Sentry to the project").

Rebased onto #2907: run 40264124350 failed Run iOS 6000.6 runtime on a sentry.io 503 for the crash envelope (fixed in #2911) and Run Android 2021.3 buildtime on an app that never initialised (fixed in #2901), then passed on a rerun of the failed jobs.

🤖 Generated with Claude Code