Fix async-execution cache keys leaking with no TTL

[Linker44]

Ticket [ENG-N/A]

Description Of Changes

cache_task_tracking_key() used cache.set() to store id-{request_id}-async-execution keys with no TTL, causing them to accumulate indefinitely — one per privacy request and request task queued. On a customer instance this resulted in 3.7M leaked keys, inflating the Redis keyspace and increasing the cost of every SCAN/KEYS operation.

Switched to cache.set_with_autoexpire() so these keys expire with the default 7-day TTL, matching the behavior of other cache keys (e.g. identity keys, encoded objects).

Code Changes

• Changed cache.set() to cache.set_with_autoexpire() in cache_task_tracking_key() (src/fides/api/util/cache.py)

Steps to Confirm

1. Queue a privacy request
2. Check the TTL of the async-execution key: redis-cli TTL id-{request_id}-async-execution — should return ~604800 (7 days)
3. Verify privacy request cancellation still works (reads the cached task ID via get_cached_task_id)
4. Verify requeuing of in-progress privacy requests still works (reads the cached task ID to check if tasks are in-flight)

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • No UX review needed
• Followup issues:
  • No followup issues
• Database migrations:
  • No migrations
• Documentation:
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Mar 11, 2026 9:02pm
fides-privacy-center	Ignored		Mar 11, 2026 9:02pm

[greptile-apps]

Greptile Summary

This PR fixes a Redis key leak where cache_task_tracking_key() was storing id-{request_id}-async-execution keys via cache.set() with no TTL, causing them to accumulate indefinitely (manifesting as 3.7 M leaked keys on a customer instance). The fix is a one-line change to use cache.set_with_autoexpire(), which applies the configured default 7-day TTL — consistent with all other Fides cache keys (identity keys, encoded objects, etc.).

• The change is minimal, targeted, and correct; set_with_autoexpire already handles the expire_time fallback internally.
• Existing TestCacheTaskTrackingKey tests validate the stored value and will continue to pass unchanged.
• No automated test asserting that the newly-stored key carries a positive TTL (e.g. cache.ttl(get_async_task_tracking_cache_key(...)) > 0) is included; the test plan is currently limited to manual redis-cli TTL verification. Adding a unit test would lock in this invariant and prevent accidental regression.

Confidence Score: 5/5

• This PR is safe to merge; it is a one-line correctness fix with no behavioural side-effects beyond adding a TTL.
• The change is minimal and well-understood: set_with_autoexpire is already used throughout the codebase for every other cache key, so this simply closes a gap. set_with_autoexpire handles the default TTL fallback internally, so the call-site change is complete. Existing tests still pass. The only gap is the absence of an automated TTL assertion test, which is a style/best-practice concern rather than a blocking issue.
• No files require special attention.

Important Files Changed

Filename	Overview
src/fides/api/util/cache.py	Single-line fix swapping cache.set() for cache.set_with_autoexpire() in cache_task_tracking_key, ensuring async-execution keys now receive the default 7-day TTL instead of persisting indefinitely.

_{Last reviewed commit: 206a589}