Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix tests that expect DBMAsync to put thread to sleep in sync mode #17847

Merged
merged 18 commits into from
Jun 18, 2024

Conversation

kozlovb
Copy link
Contributor

@kozlovb kozlovb commented Jun 14, 2024

What does this PR do?

Fixes tests that relied on main thread being put to sleep by DBMAsync.
Tests started to fail after this PR - #17716 got submitted.

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Changelog entries must be created for modifications to shipped code
  • 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

Copy link

codecov bot commented Jun 14, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.16%. Comparing base (9a6a02d) to head (85aa002).
Report is 17 commits behind head on master.

Additional details and impacted files
Flag Coverage Δ
activemq ?
cassandra ?
hive ?
hivemq ?
ignite ?
jboss_wildfly ?
kafka ?
mysql 87.84% <100.00%> (+4.93%) ⬆️
postgres 86.20% <100.00%> (+9.34%) ⬆️
presto ?
solr ?
sqlserver 88.87% <100.00%> (+6.67%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

@kozlovb kozlovb changed the title Fix tests Fix tests that expect DBMAsync to put thread to sleep in sync mode Jun 14, 2024
@kozlovb kozlovb added the qa/skip-qa Automatically skip this PR for the next QA label Jun 14, 2024
Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

3 similar comments
Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

@kozlovb kozlovb force-pushed the BorisKozlov-DBMON-4188 branch from 0135858 to 5d61b1e Compare June 17, 2024 10:49
Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

@@ -311,10 +314,12 @@ def test_statement_metrics_and_plans(
# 2) load the test queries into the StatementMetrics state
# 3) emit the query metrics based on the diff of current and last state
dd_run_check(check)
time.sleep(2)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tag sleep

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need sleep here? I thought we need either sleep or a close to zero collection interval but not both

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have an answer to this question yet.

What I know is that only in this test collection interval was set to 2s instead of 0.1 as in other tests.
link - https://github.com/DataDog/integrations-core/blob/13b7646c076108d76194c67e80c57515564fd489/sqlserver/tests/test_statements.py#L305
Also, if I reset my change in the base package and run this test with 0.1 collection interval it fails
branch - bk/test-sleep-DBMON-4188 . Which means that the sleep produced by DBMAsync was always needed for test to function.

I'll take a look at it when I have more time. Probably, tmrw morning. But I am confident that we can move forward with this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if sleep is needed regardless of the collection interval, can we just add sleep without setting the collection interval to 0.000001 to minimize the changes?

Copy link
Contributor

@jmeunier28 jmeunier28 Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding a bunch of sleeps all over the place seems like a recipe for disaster (how will people know to do this going forward??). It also feels like setting a very low collection interval is hacky / prone to future flakey-ness / not straightforward why we need it. I would just add a run_sync_blocking function or something like that to the DBMAsync job, which has the old behavior and then update the tests to use that. This is a bit weird, because we are adding production code that will only be used by tests, but we do this in plenty of places in the backend and this seems like a fair trade off in order to have reliable tests going forward. We just need to make sure this function is documented well.

Copy link

The validations job has failed; please review the Files changed tab for possible suggestions to resolve.

@@ -87,7 +88,7 @@ def test_statement_metrics_multiple_pgss_rows_single_query_signature(
# don't need samples for this test
dbm_instance['query_samples'] = {'enabled': False}
dbm_instance['query_activity'] = {'enabled': False}
dbm_instance['query_metrics'] = {'enabled': True, 'run_sync': True, 'incremental_query_metrics': True}
dbm_instance['incremental_query_metrics'] = True
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks wrong. why is incremental_query_metrics moved to the top level?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah should be
dbm_instance['query_metrics']['incremental_query_metrics'] = True
thx

@@ -311,10 +314,12 @@ def test_statement_metrics_and_plans(
# 2) load the test queries into the StatementMetrics state
# 3) emit the query metrics based on the diff of current and last state
dd_run_check(check)
time.sleep(2)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need sleep here? I thought we need either sleep or a close to zero collection interval but not both

@@ -30,15 +30,23 @@
# depend on a default schema being set on the connection
DEFAULT_FQ_SUCCESS_QUERY = "SELECT * FROM information_schema.TABLES"

CLOSE_TO_ZERO_INTERVAL = 0.0000001
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a difference between 0.0000001 and 0? Why not just zero?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0 doesn't work cause we divide by 0 when we pass this argument to DBMAsync.
So, in code there is a check that will revert 0 to default_collection_interval.
like https://github.com/DataDog/integrations-core/blob/13b7646c076108d76194c67e80c57515564fd489/sqlserver/datadog_checks/sqlserver/statements.py#L212 .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks!

@lu-zhengda lu-zhengda merged commit b9cef75 into master Jun 18, 2024
42 checks passed
@lu-zhengda lu-zhengda deleted the BorisKozlov-DBMON-4188 branch June 18, 2024 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants