Fix for pytest-asyncio bug

[sanders41]

Purpose

The pytest-asyncio plugin has a bug where tests patched with unittest mocks aren't automatically recognized as async so pytest skips them. This fixes that issue.

Changes

• Add the @pytest.mark.asyncio decorator to patched tests.

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 #1240

[pattisdr]

👍

[pattisdr]

Thanks for taking care of this change and nailing down the root cause!

[pattisdr]

will wait until this is no longer in flux ^

[sanders41]

Thanks @pattisdr I hope I caught them all with this last one, but we will see 😄

[sanders41]

Just 1 test left failing. @adamsachs or @galvana can one of you point me to what the reason may be? I don't think any change I made should have affected this test. https://github.com/ethyca/fidesops/runs/8213079793?check_suite_focus=true#step:7:198

[pattisdr]

I wonder if there's a collision in the privacy request id.

The test is failing in an area that sends high-level statistics to fideslog so we can understand how graphs change in between runs on a single privacy request if the privacy request is retried from where it failed, or is resumed from a paused state. The collections it thinks it has already processed are mailchimp collections but this is a sendgrid test.

My guess is that the privacy request id we generated happened to overlap with a privacy request created in another test. I'm guessing a restart will fix this, but we should probably move to a privacy request fixture/do better about deleting privacy requests created in testing/increase the number of possible privacy request ids generated here in the future.

privacy_request = PrivacyRequest(
            id=f"test_saas_access_request_task_{random.randint(0, 1000)}"
        )

already_processed_access_collections = ['mailchimp_instance:member', 'mailchimp_instance:messages', 'mailchimp_instance:conversations']
current_graph = {'__ROOT__:__ROOT__': {}, '__TERMINATE__:__TERMINATE__': {'sendgrid_instance:contacts': []}, 'sendgrid_instance:contacts': {'__ROOT__:__ROOT__': ['__ROOT__:__ROOT__:email->sendgrid_instance:contacts:email']}}
added_edges = ['__ROOT__:__ROOT__:email->sendgrid_instance:contacts:email']

[sanders41]

Nice find @pattisdr a collision seems like a good possibility. I restarted the tests.

[sanders41]

Previous one passed with a rerun, but a different failure https://github.com/ethyca/fidesops/runs/8213447951?check_suite_focus=true#step:7:124. This one looks different, but again I don't think any change here would have touched it.

[pattisdr]

I agree, I doubt that failure is related

[sanders41]

@pattisdr debugging code is removed so this should be ready now.