feat(Replay): Add Flag for EAP Query for Replay Details Page

[cliffordxing]

In this previous PR, a new helper function for querying EAP for replay details given a replay ID was added to the organization details file. This PR calls this new function behind a new feature flag organizations:replay-details-eap-query.

Relates To: https://linear.app/getsentry/issue/REPLAY-825/add-flag-for-reading-from-eap-for-replay-details

[linear]

REPLAY-825 Add Flag for Reading from EAP for Replay Details

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 1 line in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...y/replays/endpoints/organization_replay_details.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #103278      +/-   ##
===========================================
+ Coverage   80.69%    80.73%   +0.04%     
===========================================
  Files        9225      9232       +7     
  Lines      393916    394543     +627     
  Branches    25109     25109              
===========================================
+ Hits       317887    318552     +665     
+ Misses      75581     75543      -38     
  Partials      448       448              

[sentry]

Bug: Type mismatch in query_replay_instance_eap return value handling could cause TypeError if eap_read.query() returns a list directly.
_{Severity: MEDIUM | Confidence: 0.70}

🔍 Detailed Analysis

The query_replay_instance_eap function assumes that eap_read.query() returns a dictionary containing a "data" key, which is then accessed as snuba_response = query_replay_instance_eap(...)["data"]. However, the non-EAP path, query_replay_instance, already unwraps the data by returning execute_query(...)["data"]. This inconsistency means that if eap_read.query() returns a list directly instead of a dictionary with a "data" key, accessing ["data"] will result in a TypeError at runtime when process_raw_response is called.

💡 Suggested Fix

Verify the return structure of eap_read.query() from src/sentry/replays/lib/eap/read.py. If it returns a list directly, modify line 171 to remove the ["data"] access.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sentry/replays/endpoints/organization_replay_details.py#L163-L171

Potential issue: The `query_replay_instance_eap` function assumes that
`eap_read.query()` returns a dictionary containing a `"data"` key, which is then
accessed as `snuba_response = query_replay_instance_eap(...)["data"]`. However, the
non-EAP path, `query_replay_instance`, already unwraps the data by returning
`execute_query(...)["data"]`. This inconsistency means that if `eap_read.query()`
returns a list directly instead of a dictionary with a `"data"` key, accessing
`["data"]` will result in a `TypeError` at runtime when `process_raw_response` is
called.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

_{Reference_id: 2662889}

[billyvg]

When can this be None?

[cliffordxing]

ah, i initially thought the request.user.id could have been null, but after looking further it seems we don't need this and i can just make it int since authenticated users should always have the id. i've updated it!

[aliu39]

request.user.id can still be none when request.user is an AnonymousUser, which happens when we query the api from a script for example