ref(supergroups): extract helper for get-by-group-ids Seer call#113492
ref(supergroups): extract helper for get-by-group-ids Seer call#113492
Conversation
Co-authored-by: Claude <noreply@anthropic.com>
| ) | ||
| if response.status >= 400: | ||
| raise SeerApiError("Seer request failed", response.status) | ||
| return orjson.loads(response.data) |
There was a problem hiding this comment.
orjson.loads() on Seer API response lacks JSONDecodeError handling
The orjson.loads(response.data) call at line 40 parses the external Seer API response without catching orjson.JSONDecodeError. If Seer returns an HTML error page, empty body, or truncated JSON with a non-4xx status code (e.g., 200 with invalid content, or 3xx redirect), this will raise an unhandled exception. This matches Check 8 (Data Parsing & Deserialization) patterns where external APIs can return unexpected non-JSON responses.
Verification
Read the full file src/sentry/seer/supergroups/by_group.py and traced the data flow. The response comes from make_supergroups_get_by_group_ids_request() in src/sentry/seer/signed_seer_api.py which returns a BaseHTTPResponse from urllib3. Only status >= 400 is handled before JSON parsing. Confirmed orjson.loads() has no try/except wrapper. The endpoint in organization_supergroups_by_group.py only catches SeerApiError, not JSONDecodeError.
Suggested fix: Wrap orjson.loads() in try/except to handle malformed JSON responses from the Seer API
| return orjson.loads(response.data) | |
| import logging | |
| logger = logging.getLogger(__name__) | |
| try: | |
| return orjson.loads(response.data) | |
| except orjson.JSONDecodeError: | |
| logger.warning( | |
| "seer.supergroups.invalid_json_response", | |
| extra={ | |
| "organization_id": organization.id, | |
| "response_status": response.status, | |
| }, | |
| ) | |
| raise SeerApiError("Invalid JSON response from Seer", 502) |
Identified by Warden sentry-backend-bugs · 9PQ-N66
Similar to #113492. Move some basic issue search functionality out of the endpoint to a shared helper so that it can be reused for supergroups. For more context, we're working on a new endpoint that will fetch both issues and supergroups for those issues, and serve a combined feed. No functionality change in here. This does add some unfortunate indirection, but I figure it's worth to deduplicate a lot of the issue search logic across both endpoints. Co-authored-by: Claude <noreply@anthropic.com>
Move the actual seer request for supergroups to its own helper. This is building up to serve a blended supergroup + issues endpoint.