Fix mysql flaky test

[AAraKKe]

What does this PR do?

Fixes a flaky test I have been getting recently in several PRs. I was goingto mark it as flaky but realized it is actually easy to understand what it is doing so I decided to fix it.

Motivation

Les flakes, more trust.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.18%. Comparing base (e61ca43) to head (95d4640).
⚠️ Report is 27 commits behind head on master.

Additional details and impacted files

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4e942d4ab7

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[dkirov-dd]

Looks good overall! One small question

[eric-weaver]

I've been trying to track down systemic timing issues we see across the DBM integrations in general. Some of it stems from our DbmAsyncJob threads and their life cycle which partially comes into play here. If these changes you made stabilize the current flakiness I'm good with merging it through.

I will be following up on these and others in general in order to ensure the tests we have are more predictable and stable to timing specific races

Review from eric-weaver is dismissed. Related teams and files:

• database-monitoring-agent
  • mysql/tests/test_query_activity.py

[AAraKKe]

I've been trying to track down systemic timing issues we see across the DBM integrations in general. Some of it stems from our DbmAsyncJob threads and their life cycle which partially comes into play here. If these changes you made stabilize the current flakiness I'm good with merging it through.

I will be following up on these and others in general in order to ensure the tests we have are more predictable and stable to timing specific races

@eric-weaver, have you tried using the time-machine library? It allows you to run through time so you can, in a controll manner, make time move forward. I normally prefer freezegun, seems a bit easier to use, but I understand that time-machine is better for threaded applications. Maybe that is what you guys need to ensure that timing is not an issue anymore and you can define very specific test to validate timing as well.

You could build a helper in datadog_checks_dev (where our pytest plugin is with the fixtures we can use) to control it.