Closes []

Description Of Changes

Current Problem (Without Fix)

Privacy request gets stuck in requires_input status and has to wait for theTask graph to eventually time out to see the error message.

Proposed Fix

Added the requires input status to the request runner check.
Normal queue checkers pick up the request again with the manual task is complete, so the request can proceed normally.
If there are still other errors, they'll be handled by the normal error handling flow.

When they pick up a request that was previously stuck:

• First Check: They'll see the manual task is now complete (because we just completed it)
• Normal Flow: The request continues through the normal task execution
• Error Handling: If there are still other issues, they'll be caught and handled properly

Some Different Scenarios
Scenario 1: Manual Task Was the Only Issue

• status in awaiting input
• Queue checker picks it up
• Request completes successfully (no more errors)
  ✅ Problem solved

Scenario 2: There Are Still Other Errors

• status in awaiting input
• Queue checker picks it up
• Other errors are encountered and handled normally
• Request might go back to requires_input or error status as appropriate
  ✅ Proper error handling restored

Scenario 3: Manual Task Wasn't Actually Complete

• Status in awaiting input
• Queue checker picks it up
• _run_request detects incomplete manual task
• Raises AwaitingAsyncTaskCallback again
• Request goes back to requires_input status
  ✅ Self-correcting behavior

Code Changes

• Added a small update to how access tasks are handled for erasures.
• Updated the request runner to look at awaiting input statuses
• added some tests

Steps to Confirm

1. Add the data/dataset/postgres_example_test_dataset.yml
2. Run fidesplus pointed at this branch.
3. stop the postgres container.
4. Create an Access DSR - verify it errors correctly
5. Create and Erasure DSR - verify it errors correctly.

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
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required