Skip to content

feat: Add Filter parameter to Get-SentryTestEvent - #63

Draft
bitsandfoxes wants to merge 1 commit into
mainfrom
feat/test-event-filter
Draft

bitsandfoxes wants to merge 1 commit into
mainfrom
feat/test-event-filter

Conversation

@bitsandfoxes

@bitsandfoxes bitsandfoxes commented Oct 25, 2026 •

Copy link
Copy Markdown
Contributor

Get-SentryTestEvent takes an optional -Filter scriptblock now. When looking up events by tag, it drops the events the filter rejects before checking that exactly one is left.

The tag lookup expects exactly one event per tag. A test app can send an unrelated event that carries the same scope tag, and then the lookup fails. sentry-unity's iOS Crash Capture test hits this: on a slow simulator, sentry-cocoa's app-hang watchdog reports an App Hang Non Fully Blocked event about a second before the crash. The hang event carries the test.crash_id tag that was already set on the scope, so the lookup sees two events and polls for 300 s before failing with "Expected 1, but got 2". Over the last 30 days that happened 15 times in sentry-unity CI.

How it works:

  • Events are flattened (each entries item becomes a top-level property such as exception) before the filter runs. The filter sees the same shape the function returns, so a caller can write { $_.exception.values[0].mechanism.type -ne 'AppHang' }. The flattening moved into a private ConvertTo-SentryTestEvent helper. Both lookup paths and Get-SentryTestTransaction use it.
  • The count check still runs after filtering, so two events that both pass the filter still fail. If only rejected events have arrived so far, the function keeps polling until a matching one shows up or it times out.
  • -Filter together with -EventId throws, because an event looked up by ID can't be filtered.
  • Without -Filter nothing changes for existing callers.

Usage in sentry-unity: getsentry/sentry-unity#2899

Tested locally with Pester, mocking Find-SentryEventByTag and Get-SentryEvent with events parsed through ConvertFrom-Json -AsHashtable, the way the API client parses them: it picks the crash out of crash plus hang, still fails on two crashes plus a hang, keeps polling while only hang events exist, leaves the unfiltered behaviour alone, and rejects -Filter with -EventId. No workflow covers utils/, so this PR runs no CI of its own. sentry-unity CI covers it: with a hang forced right before the iOS crash, Sentry held a crash event and an AppHang event for the same tag, and the filtered lookup still passed on all four iOS jobs (getsentry/sentry-unity#2899, run).

🤖 Generated with Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant