fix: loosen StatsigEventSerializer validation and downgrade DetectorGroup.DoesNotExist noise

[billyvg]

Summary

Fixes two production Sentry alerts surfaced by automated monitoring.

---

Fix 1 — SENTRY-5J6Z: Statsig webhook DeserializationError (medium severity, ~17k events/day, 4826 users impacted)

Root cause: StatsigEventSerializer.user was declared as DictField(child=CharField()), which requires every value in the dict to be a plain string. Statsig server-SDK payloads (e.g. statsig-server-core-node) send nested objects for user.customIDs, user.custom, and user.statsigEnvironment. This caused every such webhook to fail with a DeserializationError before flag audit logs could be written.

Two additional fields also caused spurious failures:

• value — Statsig sends an empty string for exposure events; CharField without allow_blank=True rejects it.
• timeUUID — Sent in formats that don't satisfy DRF's UUIDField; changed to CharField since this field is unused by the handler.

Fix: Remove the child=CharField() constraint from user, add allow_blank=True to value, and relax timeUUID to CharField. None of these fields are used downstream in the audit-log construction path.

Files changed:

• src/sentry/flags/providers.py — relax StatsigEventSerializer field constraints
• tests/sentry/flags/providers/test_statsig.py — add regression test with nested user fields

---

Fix 2 — SENTRY-5R4N: DetectorGroup.DoesNotExist logged as exception (medium severity, ~27k events, 4800 users triggering noisy errors)

Root cause: _get_detector_for_group in sentry/workflow_engine/processors/detector.py used logger.exception() inside the DetectorGroup.DoesNotExist handler. logger.exception() attaches the exception traceback and triggers a Sentry capture, but this DoesNotExist is an expected condition for legacy groups that were created before the workflow engine's DetectorGroup table existed. The function already falls through correctly to two further lookup strategies; the exception capture was pure instrumentation noise.

Fix: Downgrade logger.exception() → logger.warning() so the condition is noted in logs without generating a Sentry event.

Files changed:

• src/sentry/workflow_engine/processors/detector.py — downgrade log level

---

Evidence / Reasoning

• SENTRY-5J6Z: https://sentry.sentry.io/issues/SENTRY-5J6Z/ — Seer root cause: "Overly strict validation in StatsigEventSerializer for unused fields." The actual webhook payload in the event shows user.customIDs: {"organizationId": "org_..."} (a dict) being rejected by child=CharField().
• SENTRY-5R4N: https://sentry.sentry.io/issues/SENTRY-5R4N/ — Seer root cause: "Legacy groups without DetectorGroup associations trigger a logged exception." Stack trace shows logger.exception directly after catching DetectorGroup.DoesNotExist; the surrounding code falls back to other lookups successfully.
• Claude session: https://claude.ai/code/session_0152iRwgLj2pwmC8VKUsxoKL

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

---

Generated by Claude Code

[github-actions]

🚨 Warning: This pull request contains Frontend and Backend changes!

It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently.

Have questions? Please ask in the #discuss-dev-infra channel.