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

tests: introducing keep-alive tests #1241

Open
wants to merge 1 commit into
base: branch-hackathon
Choose a base branch
from

Conversation

fruch
Copy link

@fruch fruch commented Feb 13, 2025

introducing test that validates the keep-alive behavier

those tests are based on:
com.datastax.oss.driver.core.heartbeat.HeartbeatIT

Pre-review checklist

  • I have split my patch into logically separate commits.
  • All commit messages clearly explain what they change and why.
  • I added relevant tests for new features and bug fixes.
  • All commits compile, pass static checks and pass test.
  • PR description sums up the changes and reasons why they should be introduced.
  • I have provided docstrings for the public items that I want to introduce.
  • I have adjusted the documentation in ./docs/source/.
  • I added appropriate Fixes: annotations to PR description.

introducing test that validates the keep-alive behavier

those tests are based on:
`com.datastax.oss.driver.core.heartbeat.HeartbeatIT`
) {
let mut total_keep_alives: u32 = 0;
let start = tokio::time::Instant::now();
while total_keep_alives < expected_number_of_keep_alive && start.elapsed() < timeout {
Copy link
Author

Choose a reason for hiding this comment

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

I'm not sure this is the best idiomatic way of doing such a thing

Copy link
Collaborator

@Lorak-mmk Lorak-mmk Feb 13, 2025

Choose a reason for hiding this comment

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

It is not. I'd do it roughly like that (didn't test the code, so it may not compile):

tokio::time::timeout(timeout,  async move {
    for _ in 0..expected_number_of_keep_alive {
        request_rx.recv().await.unwrap();
    }
});

#[cfg(not(scylla_cloud_tests))]
async fn should_send_heartbeat_on_regular_connection() {
/*
// Prime a simple query so we get at least some results
Copy link
Author

Choose a reason for hiding this comment

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

didn't got to implementing all of the tests, left the java code as skeletons

@fruch
Copy link
Author

fruch commented Feb 13, 2025

test seems to be failing in CI, when working locally...
I have zero clue, as for why...

Copy link

cargo semver-checks found no API-breaking changes in this PR! 🎉🥳
Checked commit: b6fde99

Comment on lines +14 to +27
/// Waits for a specified number of keep-alive messages to be received within a given timeout period.
///
/// # Arguments
///
/// * `request_rx` - An `UnboundedReceiver` that receives the keep-alive messages.
/// * `expected_number_of_keep_alive` - The number of keep-alive messages expected to be received.
/// * `timeout` - The maximum duration to wait for the expected number of keep-alive messages.
///
/// # Panics
///
/// This function will panic if the number of received keep-alive messages does not match the
/// expected number within the timeout period.
///
async fn wait_for_keep_alive<T>(
Copy link
Collaborator

Choose a reason for hiding this comment

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

👍 I really like that you put such extensive comment, such things are sadly missing in many of our tests.

Copy link
Author

Choose a reason for hiding this comment

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

It's mostly copilot, I just removed a few unneeded things after him

Comment on lines +56 to +59
.unwrap();

// TODO: No way to get node status, no as in java-driver

Copy link
Collaborator

Choose a reason for hiding this comment

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

WDYM by node status? Do you need information if the driver is connected to a given node?
If so you can get it with session.cluster_state().get_nodes_info()[node_idx].is_connected()

@Lorak-mmk
Copy link
Collaborator

test seems to be failing in CI, when working locally... I have zero clue, as for why...

How are you running the tests?
I checkout out this PR and run make ccm-test, and got the same failures as in "CCM tests" CI workflow.

I started to look into "should_not_send_heartbeat_during_protocol_initialization", and I don't understand why it fails.
The session fails because of connection broken when sending Options request - as expected.
So then why we see no feedback of this request on the channel? @wprzytula please help here.

@muzarski
Copy link
Contributor

muzarski commented Feb 16, 2025

test seems to be failing in CI, when working locally... I have zero clue, as for why...

How are you running the tests? I checkout out this PR and run make ccm-test, and got the same failures as in "CCM tests" CI workflow.

I started to look into "should_not_send_heartbeat_during_protocol_initialization", and I don't understand why it fails. The session fails because of connection broken when sending Options request - as expected. So then why we see no feedback of this request on the channel? @wprzytula please help here.

The reason is very simple (yet not so easy to spot). These tests are placed under ccm_integration. make ccm-test does not set SCYLLA_URI<X> env variables. Because of that, the default addresses (127.0.0.1-3) are used (see the details in test_with_3_node_cluster. If I run:

SCYLLA_URI=172.42.0.2:9042 SCYLLA_URI2=172.42.0.3:9042 SCYLLA_URI3=172.42.0.4:9042 RUSTFLAGS="--cfg ccm_tests" RUST_LOG=trace cargo test --test ccm_integration

all tests are passing.

These tests should be moved to integration - we do not use ccm in these tests (at least in the tests that are already implemented).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants