Skip to content

server_info() always returns empty information? #1121

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

Closed
NuSkooler opened this issue Sep 26, 2023 · 4 comments
Closed

server_info() always returns empty information? #1121

NuSkooler opened this issue Sep 26, 2023 · 4 comments
Assignees
Labels
defect Suspected defect such as a bug or regression

Comments

@NuSkooler
Copy link

NuSkooler commented Sep 26, 2023

What version were you using?

  • async-nats 0.31.0
  • Docker image a5455cadbb1b

What environment was the server running in?

Linux, x86_64

Is this defect reproducible?

let client = async_nats::connect_with_options(server_addresses, connect_opts).await.expect("We should keep retrying");

let info = client.server_info();
tracing::info!(
    server_id = info.server_id,
    server_name = info.server_name,
    version = info.version,
    max_payload = info.max_payload,
    "Connection with server established"
);

Given the capability you are leveraging, describe your expectation?

Populated server info

Given the expectation, what is the defect you are observing?

Connection with server established server_id="" server_name="" version="" max_payload=0

As an aside, would it be possible to make this query-able via the Event callback? This seems like a more opportune time.

@NuSkooler NuSkooler added the defect Suspected defect such as a bug or regression label Sep 26, 2023
@caspervonb caspervonb self-assigned this Oct 2, 2023
@Jarema
Copy link
Member

Jarema commented Oct 2, 2023

@NuSkooler What version of server are you running?

Quick tests shows everything seems fine:

test:


    #[tokio::test]
    async fn server_info() {
        let server = nats_server::run_basic_server();
        let client = async_nats::connect(server.client_url()).await.unwrap();

        println!("server info: {:#?}", client.server_info());
    }

server info: ServerInfo {
    server_id: "NBCXGFLRO7BJJSF37EC5MBPHTYC762H5HWDV5JDWEMBNN4TBLIEBFFQL",
    server_name: "NBCXGFLRO7BJJSF37EC5MBPHTYC762H5HWDV5JDWEMBNN4TBLIEBFFQL",
    host: "0.0.0.0",
    port: 63527,
    version: "2.10.2-RC.7",
    auth_required: false,
    tls_required: false,
    max_payload: 1048576,
    proto: 1,
    client_id: 6,
    go: "go1.21.1",
    nonce: "",
    connect_urls: [],
    client_ip: "::1",
    headers: true,
    lame_duck_mode: false,
}

@Jarema Jarema self-assigned this Oct 2, 2023
@Jarema
Copy link
Member

Jarema commented Oct 2, 2023

There is one scenario when this can happen:

If you set retry_on_initial_connect() flag, which changes a little initial connection handling.
Howerver, it is filled as soon as connection is established properly:


    #[tokio::test]
    async fn server_info() {
        tracing_subscriber::fmt().init();
        let server = nats_server::run_basic_server();
        let client = async_nats::ConnectOptions::new()
            .retry_on_initial_connect()
            .connect(server.client_url())
            .await
            .unwrap();

        // can be empty, as with `retry_on_initial_connect` immediately innitiates connection attempt,
        // but does not wait for its result.
        let info = client.server_info();
        println!("server info: {:#?}", info);
        // When connection is there, info is properly filled.
        tokio::time::sleep(Duration::from_millis(100)).await;
        let info = client.server_info();
        println!("server info: {:#?}", info);

        tracing::info!(server_id = info.server_id, "connection established");
    }

We will consider adding that information to Event::Connect.

@NuSkooler
Copy link
Author

@Jarema Thanks you for your response! I should have included my connection options - I am using retry_on_initial_connect().

Thank you for considering Event::Connect!

@Jarema
Copy link
Member

Jarema commented Oct 2, 2023

I'm closing this issue.
The change in Event::Connect will be considered before the 1.0.0 issue list is fully addressed.

@Jarema Jarema closed this as completed Oct 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect Suspected defect such as a bug or regression
Projects
None yet
Development

No branches or pull requests

3 participants