Fix Corner Case: Retrieving Access Results from Cache on Retry [#1348]

[pattisdr]

Purpose

Fix bug where erasure count confirmations may be returned instead of selected access request results when attempting to get access requests from the cache.

Because erasure requests are run after access requests, there normally aren't erasure results in the cache when we attempt to get access results. However, it's possible to run into this in the case of "restarting a privacy request from failure". If we were retrying a privacy request from a checkpoint that had already erased some data, we could possibly return erasure results instead of access results for selected collections, depending on if the access or erasure key was accessed last.

Changes

• Be more specific about the key's prefix when retrieving access results with TaskResources.get_all_cached_objects instead of using a key prefix that overlaps with erasure results.

Checklist

• Update CHANGELOG.md file
  • Merge in main so the most recent CHANGELOG.md file is being appended to
  • Add description within the Unreleased section in an appropriate category. Add a new category from the list at the top of the file if the needed one isn't already there.
  • Add a link to this PR at the end of the description with the PR number as the text. example: #1
• Applicable documentation updated (guides, quickstart, postman collections, tutorial, fidesdemo, database diagram.
• If docs updated (select one):
  • documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
  • documentation issue created (tag docs-team to complete issue separately)
• Good unit test/integration test coverage
• This PR contains a DB migration. If checked, the reviewer should confirm with the author that the down_revision correctly references the previous migration before merging
• The Run Unsafe PR Checks label has been applied, and checks have passed, if this PR touches any external services

Ticket

Fixes #1348

[pattisdr]

Thanks so much @sanders41!