test: Fix leaked attachment response and expired seer replay fixture

[sentry-junior]

Follow-up to the earlier flaky backend test fixes. Two test-only commits, no src/ changes. Neither commit changes assertions or test ordering, and neither adds skips, sleeps, or reruns.

Close the second superuser attachment download response

test_superuser_can_access in tests/sentry/api/endpoints/test_event_attachment_details.py left its second streaming attachment response unconsumed and unclosed. When garbage collection finalized it later, the ResourceWarning showed up as a PytestUnraisableExceptionWarning in whatever unrelated test happened to be running. Over the last 14 days pytest-sentry recorded 592 of these warning events across 13 tests.

The fix consumes and closes the second response the same way the first one already is.

• Before: reproduced 5/5 locally
• After: 20/20 passes

Store the 89-day replay with 90-day retention

test_get_replay_metadata_short_id in tests/sentry/seer/agent/test_tools.py stores replay rows timestamped 89 days ago, but mock_replay defaults to retention_days=30. The ClickHouse TTL is timestamp + retention_days, so those rows are already expired when they're inserted. Locally, system.part_log showed a TTL-delete merge (TTLDeleteMerge) dropping them about 6 seconds after insertion. The test passes today only because its lookup runs before that merge.

The fix passes retention_days=90 on the two 89-day rows, so they stay inside retention like real data would. This is preventive: 0 CI failures in the last 14 days. With the fix the relevant tests pass 2/2, and the TTL probe finds no expired rows.

Investigated, not changed

• TTL sweep: I swept about 13.2k Snuba-backed tests. No other test uses a fixed timestamp that's still inside retention and will age out soon. The other rows that were already expired at insert either don't affect assertions or are expired on purpose.
• Readthrough cache: a synthetic probe reproduced a stale read. In the sweep, though, only 3 tests had confirmed cache hits after a write, and all 3 assert on Postgres, not on the affected Snuba data. I didn't find a Sentry-side fix that keeps test fidelity.
• Snuba read timeouts: I saw occasional 30s Snuba read timeouts but didn't confirm a root cause, so there's no code change for them here.

via @joshuarli.

--

View Junior Session [Sentry]